在 gdb 中查找环境变量地址时奇怪的事情答案

【问题标题】：Curious thing when finding environment variable address in gdb在 gdb 中查找环境变量地址时奇怪的事情
【发布时间】：2012-07-18 04:50:03
【问题描述】：

最近我正在用我的 Ubuntu11.10 在论文 Bypassing non-executable-stack during exploitation using return-to-libc 上做一些 Return-to-libc 攻击实验。

在进行实验之前，我关闭了 ALSR。

根据论文，我可以在gdb中找到环境变量SHELL="/bin/bash"的地址（使用gdb调试我要攻击的程序）：

但是当我尝试使用该地址进行Return-to-libc实验时发现该地址错误。

然后我写了一个简单的程序来获取环境变量地址：

当我在终端中运行这个程序时，我得到了正确的地址：

有了这个地址，我可以做攻击。

我还找到了与此相关的question。但是答案并没有真正的意义（第二个可能更好）。

请告诉我一些细节。

【问题讨论】：

【解决方案1】：

从您的屏幕截图中，我假设您在 32 位英特尔平台上运行。我还没有花时间全面研究这个问题的答案，但这些是值得注意的点：

所以，我的猜测是这里发生的事情是：

环境块和命令行参数在启动过程中的某个时间点以压缩形式推送到用户地址空间的末尾。
在 GDB 或终端中运行程序时，环境的内容会有所不同。例如，我在 GDB 下运行时注意到“_=/usr/bin/gdb”，我敢打赌只有在 GDB 下运行时才会出现。

结果是，虽然您的固定指针倾向于落在环境块中间的某个位置，但它不会每次都落在同一个位置，因为环境本身在运行之间会发生变化。

【讨论】：

我也同意环境不同。这是否意味着我阅读的论文是错误的？
@KUN：错了？嗯，总体思路是有道理的。但是，正如您所展示的，他们的漏洞利用示例需要工作。这些事情是出了名的繁琐（毕竟，你真的不“应该”以这种方式与程序交互），并且通常需要大量的专业知识才能完成。我怀疑作者理解您可能遇到的困难，并认为解决这些困难是“留给读者的练习”。
@KUN：哦，看来我读得不够远。他们确实遇到了这个问题（在下一页）。他们还讨论了他们是如何解决的。
实际上他们再次通过 gdb 解决了这个问题，我尝试过但失败了。这就是我使用“getenv”获取地址的原因。
@KUN：他们通过使用 GDB 打开核心转储文件解决了这个问题。这是一个不同的场景，区别很重要。