金丝雀是否可以防止返回到 libc 和面向返回的编程攻击?
我试图了解如果使用金丝雀,返回到 libc 和面向返回的编程漏洞是否/如何可能。
金丝雀将被放置在堆栈上的返回值和要溢出的缓冲区之间,并且需要被覆盖才能将返回值更改为库函数或计算的位置。 Canary 自 1997 年 (StackGuard) 以来就已出现,而 ROP 是 2007 年首次引入的技术 (Shacham)。
金丝雀能让这些类型的攻击变得不可能吗?
I am trying to understand if/how return-into-libc and return-oriented programming exploits are possible if a canary is being used.
A canary would be placed on the stack in between the return value and the buffer to be overflown, and would need to be overwritten in order to change the return value to the location of a library function or computation. Canaries have been around since 1997 (StackGuard) and ROP is a technique first introduced in 2007 (Shacham).
Does a canary make these types of attacks impossible?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
不,事实并非如此。它使得执行 return-to-libc 或 ROP 变得更加困难,但它绝对不是对抗此类攻击的灵丹妙药。
首先,堆栈金丝雀只能防止由于缓冲区溢出而导致返回地址崩溃。但还有其他方法可以破坏内存:间接指针覆盖或格式字符串漏洞仅举两例。
其次,可以通过用原始值覆盖堆栈金丝雀来绕过它们。我并不是说这在现代实现中很容易,但它肯定不是不可能。
第三,虽然这些攻击被称为返回-to-libc和返回面向编程,但谁说我们需要返回指令来执行这些攻击?这些攻击可以通过破坏处理器加载和跳转到的任何内存位置来发起。最常见的例子是函数指针。但我们也可以覆盖 GOT 或
longjmp
缓冲区。 (作为旁注,已经表明 ROP 可以在不使用的情况下执行任何返回指令!)第四个原因不是堆栈金丝雀本身的弱点,而是大多数实现之一。堆栈金丝雀通常只放置在具有基于堆栈的字符缓冲区且大小至少为 8 的函数中。因此,这些实现不会检测其他缓冲区中的溢出。 此漏洞使用了整数数组中的溢出,因此无法由堆栈金丝雀检测到。
No, it doesn't. It makes it more difficult to perform return-to-libc or ROP but it is definitely no silver bullet against such attacks.
First of all, stack canaries only protect against return address smashing through buffer overflows. But there are other ways to corrupt memory: indirect pointer overwrite or format string vulnerabilities to name two.
Second, stack canaries may be bypassed by overwriting them with the original value. I'm not saying this is easy on modern implementations but it certainly isn't impossible.
Third, although the attacks are called return-to-libc and Return Oriented Programming, who says we need return instructions to carry out those attacks? These attacks can be initiated by corrupting any memory location from which the processor will load and address to jump to. The most common example is a function pointer. But we could also overwrite the GOT or
longjmp
buffers. (As a side note, it has been shown that ROP can be performed without using any return instructions!)The fourth reason is not a weakness of stack canaries in se but one of most implementations. Stack canaries are normally only placed in functions that have a stack based character buffer with a size of at least 8. Those implementation will therefore not detect overflows in other buffers. This exploit used an overflow in an integer array so it could not be detected by stack canaries.
这是一个解释使用 gcc 创建的金丝雀的网站。 http://xorl.wordpress.com/2010/ 10/14/linux-glibc-stack-canary-values/。
由于在执行 ret 指令之前会检查金丝雀,因此如果您覆盖金丝雀(在大多数情况下,为了覆盖堆栈上的返回地址,您必须这样做),您的漏洞利用将会失败。由于 ROP 和 Return to Lib c 也会覆盖返回地址,因此这两种方法都不起作用。
Here is a website that explains canaries created with gcc. http://xorl.wordpress.com/2010/10/14/linux-glibc-stack-canary-values/.
Since the canary is checked before the ret instruction is executed, your exploit will fail if you overwrite the canary (which in most cases you have to do in order to overwrite the return address on the stack). Since ROP and Return to Lib c also overwrite the return address, both methods will not work.