/GS 编译器选项 Micorsoft 开发的在返回地址之前添加了一个额外的cookie,并且在返回之前检查了cookie,如果它是完整的那么返回地址是安全的
为什么这个假设会成立?在我的理解中,这只是让黑客的生活变得更难现在保持 cookie 完好无损。
/GS 编译器选项 Micorsoft 开发的在返回地址之前添加了一个额外的cookie,并且在返回之前检查了cookie,如果它是完整的那么返回地址是安全的
为什么这个假设会成立?在我的理解中,这只是让黑客的生活变得更难现在保持 cookie 完好无损。
堆栈 cookie(也称为“金丝雀”)不会阻止返回地址被覆盖,但它增加了代码在命运地跟随被覆盖的返回地址之前注意到覆盖的机会。
这是启发式的:想法是大多数缓冲区溢出最终导致覆盖返回地址,从堆栈缓冲区顺序进行,cookie 插槽的“另一侧”,因此也将覆盖 cookie。“保持 cookie 完整”要求攻击者能够以某种方式进行“跳跃溢出”(这种情况会发生,但很少发生),或者可以获取 cookie 值,以便他可以用自己覆盖 cookie 值。获取 cookie 值很困难,因为它通常是在执行时随机选择的(细节因操作系统和操作系统版本而异),并且不做广告;在极少数情况下,攻击者可以从另一个可利用漏洞的后果中间接获取 cookie 值。
在实践中,堆栈 cookie 使攻击者的生活变得更加困难,但影响相当大。作为一种防御机制,它不是 100% 有效的,但也不是很容易解决的。
堆栈金丝雀通过在将返回地址从堆栈移动到 EIP 之前首先检查金丝雀值来保护堆栈上的返回地址。为了用基于堆栈的缓冲区溢出覆盖堆栈上的返回地址,canny 必须被覆盖。如果已知堆栈上的返回地址已被覆盖,则程序可以安全退出,而无需将执行流程传递给攻击者。