What indicates if / proc / PID / maps shows zero for all addresses?
I am debugging a Linux DNS server issue. Curiously, when I look /proc/PID/maps
for the DNS server process, this is what I get:
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]
I've never seen anything like it before. All addresses except the vsyscall page are zero! Do you know what this means?
source to share
I found a discussion on Valgrind's email list when someone had the same problem. The problem was that the kernel was patched with PaX patches, one of which prevents you from looking at /proc/pid/maps
.
Quote about the patch from wikipedia
The second and third classes of attacks are also possible with 100% reliability, if the attacker needs to know the location of the address space in advance and obtain this knowledge by reading the address space of the attacked task. This is possible if the target has a bug that leaks information, for example, if the attacker has access to / proc / (pid) / maps. There is an obscurity patch that NULL outputs values for address ranges and inodes in every source of information accessible from the user area to close most of these holes; however, it is not currently included in PaX.
Although the patch is not currently enabled, the issue on the mailing list has been resolved using the PaX utility. That is, it could be changed with a chpax
utility that does binary-based permission modification, which allows you to disable restrictions on a specific binary.
source to share