我必须做一个关于“有毒空字节（glibc）”的10分钟演讲。 我搜索了很多关于它但没有发现任何东西，我需要帮助，因为操作系统linux和内存和进程管理不是我的事。
这里是original article，这里有一个old article关于同一个问题，但另一个版本。
我想要的是对问题的旧版本和新版本的简短解释或/和足够的参考资料，我可以更好地了解此安全威胁。
答案 0 :(得分：2)
为了开始理解这种攻击是如何工作的，你至少需要对CPU如何工作，内存如何工作，什么是＆＃34;堆＆＃34; ＆＃34; stack＆＃34;一个进程是什么，指针是什么，libc是什么，链接列表是什么，如何在机器级实现函数调用（包括对函数指针的调用），malloc和free的函数来自C库有，等等。希望你至少掌握一些C编程的基础知识？ （如果没有，您可能无法及时完成此任务。）
如果你有一对＆＃34;差距＆＃34;在您对上述基本主题的了解中，请尽快阅读书籍并填写。如果需要，请与他人交谈，以确保您理解他们。然后仔细阅读以下内容。这不会解释您链接的文章中的所有内容，但会给您一个良好的开端。准备好了？让我们开始......
C字符串是＆＃34;以null结尾＆＃34;。这意味着字符串的结尾由零字节标记。例如，字符串"abc"在内存中表示为（十六进制）：0x61 0x62 0x63 0x00。请注意，由于终止为空，3个字符的字符串实际上需要 4 个字节。
现在，如果您这样做：
char *buffer = malloc(3); // not checking for error, this is just an example
strcpy(buffer, "abc");
...然后终止null（零字节）将超过缓冲区的末尾并覆盖某些内容。我们分配了一个3字节的缓冲区，但是将 4 字节复制到其中。因此，在缓冲区结束后立即存储在字节中的任何内容都将被零字节替换。
这就是__gconv_translit_find中发生的事情。他们有一个缓冲区，它已经被分配了足够的空间来将".so"（包括终止空字节）附加到字符串的末尾。但他们从错误的位置开始在中复制".so"。他们将复制操作开始一个字节太远到＃34;右边＃34;所以终止空字节超过了缓冲区的末尾并覆盖了一些东西。
现在，当您调用malloc以获取动态分配的缓冲区时，malloc的大多数实现实际上在缓冲区之前存储了一些内务处理数据。例如，它们可能存储缓冲区的大小。稍后，当您将该缓冲区传递给free以释放内存时，可以将其重新用于其他内容，它会发现＆＃34;隐藏＆＃34;数据就在缓冲区开始之前，并且会知道你实际上有多少字节的内存free。 malloc也可以隐藏＆＃34;其他内务处理数据在同一位置。 （在您提到的2014年文章中，使用的malloc的实现也存储了一些＆＃34; flag＆＃34;位。）
文章中描述的攻击将精心设计的参数传递给命令行程序，旨在触发__gconv_translit_find中的缓冲区溢出错误，使得终止空字节将消除＆＃34 ;标志＆＃34;由malloc存储的位 - 不是溢出的缓冲区的标志位，而是另一个缓冲区的那些在之后分配的 >溢出的那个。 （由于malloc在分配缓冲区的开头之前存储了额外的内务数据，并且我们正在超越之前的缓冲区。您可以关注吗？）
本文展示了一个图表，其中0x00000201存储在溢出的缓冲区之后。溢出的空字节清除底部1并将其更改为0x00000200。一开始这可能没有意义，直到你记得x86 CPU是小端的 - 如果你不明白什么＆＃34; little-endian＆＃34;和＃34; big-endian＆＃34; CPU，查找它。
稍后，其标志位被清除的缓冲区将传递给free。事实证明，消除一个标志位＆＃34;混淆＆＃34; free反过来也会覆盖其他一些内存。 （您必须了解GNU libc使用的malloc和free的实现，以便了解其原因。）
通过仔细选择原始程序的输入参数，您可以进行设置，以便由＆＃34;混淆＆＃34; free用于称为tls_dtor_list的内容。这是由GNU libc维护的链表，它包含指向主程序退出时必须调用的某些函数的指针。
因此tls_dtor_list被覆盖。攻击者已经设置得恰到好处，因此覆盖的tls_dtor_list中的函数指针将指向他们想要运行的一些代码。当主程序退出时，libc中的一些代码遍历该列表并调用每个函数指针。结果：攻击者的代码已执行！
现在，在这种情况下，攻击者已经可以访问目标系统。如果他们所能做的只是运行一些具有自己帐户权限级别的代码，那么它们无法在任何地方获取。他们希望使用 root （管理员）权限运行代码。怎么可能？这是有可能的，因为有缺陷的程序是由root拥有的 setuid 程序。如果你不知道＆＃34; setuid＆＃34; Unix中的程序，查找并确保您理解它，因为这也是整个漏洞利用的关键。
这完全是关于2014年的文章 - 我没有看过1998年的文章。祝你好运！