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