我正在调试Linux DNS服务器的问题。奇怪的是，当我查看/proc/PID/maps的DNS服务器进程时，这就是我得到的结果：
00000000-00000000 r-xp 00000000 00:0e 2344 /usr/sbin/unbound
00000000-00000000 rw-p 00000000 00:0e 2344 /usr/sbin/unbound
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:00 0 [heap]
00000000-00000000 rw-p 00000000 00:00 0 [heap]
00000000-00000000 r-xp 00000000 00:0e 2009 /usr/lib/engines/libgost.so (deleted)
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 2009 /usr/lib/engines/libgost.so (deleted)
00000000-00000000 r-xp 00000000 00:0e 2016 /usr/lib/engines/libpadlock.so (deleted)
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 2016 /usr/lib/engines/libpadlock.so (deleted)
00000000-00000000 r-xp 00000000 00:0e 2333 /lib/libz.so.1.2.8
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 2333 /lib/libz.so.1.2.8
00000000-00000000 r-xp 00000000 00:0e 1760 /lib/libdl-0.9.33.2.so
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 r--p 00000000 00:0e 1760 /lib/libdl-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:0e 1760 /lib/libdl-0.9.33.2.so
00000000-00000000 r-xp 00000000 00:0e 3083 /usr/lib/libgcc_s.so.1
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 3083 /usr/lib/libgcc_s.so.1
00000000-00000000 r-xp 00000000 00:0e 1761 /lib/libuClibc-0.9.33.2.so
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 r--p 00000000 00:0e 1761 /lib/libuClibc-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:0e 1761 /lib/libuClibc-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 r-xp 00000000 00:0e 3085 /lib/libpthread-0.9.33.2.so
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 r--p 00000000 00:0e 3085 /lib/libpthread-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:0e 3085 /lib/libpthread-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 r-xp 00000000 00:0e 2002 /lib/libcrypto.so.1.0.0 (deleted)
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 2002 /lib/libcrypto.so.1.0.0 (deleted)
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 r-xp 00000000 00:0e 3181 /usr/lib/libevent-2.0.so.5.1.9
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 3181 /usr/lib/libevent-2.0.so.5.1.9
00000000-00000000 r-xp 00000000 00:0e 3189 /usr/lib/libldns.so.1.6.17
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 3189 /usr/lib/libldns.so.1.6.17
00000000-00000000 r-xp 00000000 00:0e 2335 /lib/libssl.so.1.0.0 (deleted)
00000000-00000000 ---p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:0e 2335 /lib/libssl.so.1.0.0 (deleted)
00000000-00000000 r-xp 00000000 00:0e 1755 /lib/ld64-uClibc-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 rw-p 00000000 00:00 0
00000000-00000000 r-xp 00000000 00:00 0 [vdso]
00000000-00000000 r--p 00000000 00:0e 1755 /lib/ld64-uClibc-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:0e 1755 /lib/ld64-uClibc-0.9.33.2.so
00000000-00000000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r--p 00000000 00:00 0 [vsyscall]
我以前从未见过这样的事情。除vsyscall页面外，所有地址都为零！你知道这意味着什么吗？
答案 0 :(得分：2)
当有人遇到同样的问题时，我找到了discussion in Valgrind mail list。问题是内核已经使用PaX补丁修补，其中一个补丁不允许查看/proc/pid/maps。
关于补丁from wikipedia
的引用如果攻击者需要预先知道地址空间布局并且可以通过读取受攻击任务的地址空间来获得这些知识，那么第二类和第三类攻击也可以100％可靠。如果目标具有泄漏信息的错误，例如，如果攻击者可以访问/ proc /（pid）/ maps，则这是可能的。有一个默认补丁，它可以清除每个信息源中的地址范围和索引节点的值，这些信息源可以从用户空间访问，以关闭大多数这些漏洞;但是，它目前不包含在PaX中。
尽管当前未包含该补丁的短语，但邮件列表中的问题已通过PaX实用程序解决。即可以使用chpax utility进行更改，该AWS SDK guide for PHP: Stream Wrappers基于每个二进制进行权限修改，从而允许禁用特定二进制文件的限制。