如果使用金丝雀,我试图了解是否/如何返回到 libc 和面向返回的编程漏洞。
金丝雀将被放置在返回值和要溢出的缓冲区之间的堆栈上,并且需要被覆盖才能将返回值更改为库函数或计算的位置。Canaries 自 1997 年就出现了 (StackGuard),而 ROP 是 2007 年首次引入的技术 (Shacham)。
金丝雀是否使这些类型的攻击成为不可能?
如果使用金丝雀,我试图了解是否/如何返回到 libc 和面向返回的编程漏洞。
金丝雀将被放置在返回值和要溢出的缓冲区之间的堆栈上,并且需要被覆盖才能将返回值更改为库函数或计算的位置。Canaries 自 1997 年就出现了 (StackGuard),而 ROP 是 2007 年首次引入的技术 (Shacham)。
金丝雀是否使这些类型的攻击成为不可能?
金丝雀是否使这些类型的攻击成为不可能?
不,它没有。它使执行 return-to-libc 或 ROP 变得更加困难,但它绝对不是对付此类攻击的灵丹妙药。
首先,堆栈金丝雀只能防止通过缓冲区溢出破坏返回地址。但是还有其他方法可以破坏内存:间接指针覆盖或格式字符串漏洞仅举两个。
其次,可以通过用原始值覆盖堆栈金丝雀来绕过它们。我并不是说这在现代实现中很容易,但它肯定不是不可能的。
第三,虽然这些攻击被称为return -to-libc 和Return Oriented Programming,但谁说我们需要返回指令来执行这些攻击?这些攻击可以通过破坏处理器将加载的任何内存位置和要跳转到的地址来启动。最常见的例子是函数指针。但我们也可以覆盖GOT或longjmp
缓冲区。(附带说明,已经证明可以在不使用任何返回指令的情况下执行 ROP !)
第四个原因不是 se 中堆栈金丝雀的弱点,而是大多数实现之一。堆栈金丝雀通常只放置在具有基于堆栈的字符缓冲区大小至少为 8 的函数中。因此,这些实现不会检测其他缓冲区中的溢出。该漏洞利用在整数数组中使用溢出,因此堆栈金丝雀无法检测到它。
这是一个解释使用 gcc 创建的金丝雀的网站。http://xorl.wordpress.com/2010/10/14/linux-glibc-stack-canary-values/。由于在执行 ret 指令之前检查了金丝雀,因此如果您覆盖金丝雀,您的利用将失败(在大多数情况下,您必须这样做才能覆盖堆栈上的返回地址)。由于 ROP 和 Return to Lib c 也覆盖了返回地址,因此这两种方法都不起作用。