Symbol addresses during load-time linking vs run-time linking in Linux Symbol addresses during load-time linking vs run-time linking in Linux c c

Symbol addresses during load-time linking vs run-time linking in Linux


  1. Yes, it's ASLR.

  2. Because PIE (Position Independent Executables) is quite expensive (in performance). So many systems do the tradeoff where they randomize libraries because they have to be position independent anyway, but don't randomize executables because it costs too much performance. Yes, it is more vulnerable this way, but most security is a tradeoff.

  3. Yes, don't search symbols through the handle, instead use RTLD_DEFAULT. It's generally a bad idea to have two instances of the same dynamic library loaded like this. Some systems can just skip loading a library in dlopen if they know the same library is already loaded and what the dynamic linker considers "the same library" can change depending on your library path. You're very much in the territory of quite badly/weakly defined behavior here that has evolved over the years more to deal with bugs and problems and less through deliberate design.

Note that RTLD_DEFAULT will return the address of the symbol in the main executable or the first (load time) loaded dynamic library and the dynamically loaded library will be ignored.

Also, another thing worth keeping in mind is that if you reference var in libhello it will always resolve the symbol from the load time version of the library even in the dlopen:ed version. I modified func to return var and added this code to your example code:

int (*fn)(void) = dlsym(h, "func");int *vp;var = 17;printf("%d %d %d %p\n", var, func(), fn(), vp);vp = dlsym(h, "var");*vp = 4711;printf("%d %d %d %p\n", var, func(), fn(), vp);vp = dlsym(RTLD_DEFAULT, "var");*vp = 42;printf("%d %d %d %p\n", var, func(), fn(), vp);

and get this output:

$ gcc main.c -L. -lhello -ldl && LD_LIBRARY_PATH=. ./a.out17 17 17 0x7f2e11bec02c17 17 17 0x7f2e11bec02c42 42 42 0x601054Address  Load-time linking    Run-time linking-------  -----------------    ----------------&var     0x0000000000601054   0x0000000000601054&func    0x0000000000400700   0x0000000000400700


What you see depends on many variables. Here on a Debian 64bit I got in my first try

Address  Load-time linking    Run-time linking-------  -----------------    ----------------&var     0x0000000000600d58   0x0000000000600d58&func    0x00000000004006d0   0x00000000004006d0

Which means, that dlopen used the already linked library, which your system seems not to do. To get advantage of ASLR, you need to compile main.c with position independend code: gcc -fPIC main.c ./libhello.so -ldl.

Address  Load-time linking    Run-time linking-------  -----------------    ----------------&var     0x00007f4e6cec6944   0x00007f4e6cec6944&func    0x00007f4e6ccc6670   0x00007f4e6ccc6670


I hope this hint can help you.

  1. The main program is an ELF file, and need to relocation. And the relocation occurs at the loading time. So the var and func address in the main program has relocated before you call the dlsym.

  2. the dlsym func return the symbol address in the OS ad runtime without relocation, this address is in the SO mapping region.

And you can use the mapping info to find the different:

wutiejun@linux-00343520:~/Temp/sotest> LD_LIBRARY_PATH=./ ./testAddress  Load-time linking    Run-time linking-------  -----------------    ----------------&var     0x000000000804a028   0x00000000f77a9014&func    0x0000000008048568   0x00000000f77a744cwutiejun@linux-00343520:~> cat /proc/7137/maps08048000-08049000 r-xp 00000000 08:02 46924194                           /home/wutiejun/Temp/sotest/test08049000-0804a000 r--p 00000000 08:02 46924194                           /home/wutiejun/Temp/sotest/test0804a000-0804b000 rw-p 00001000 08:02 46924194                           /home/wutiejun/Temp/sotest/test0804b000-0806c000 rw-p 00000000 00:00 0                                  [heap]f75d3000-f7736000 r-xp 00000000 08:02 68395411                           /lib/libc-2.11.3.sof7736000-f7738000 r--p 00162000 08:02 68395411                           /lib/libc-2.11.3.sof7738000-f7739000 rw-p 00164000 08:02 68395411                           /lib/libc-2.11.3.sof7739000-f773c000 rw-p 00000000 00:00 0f773c000-f7740000 r-xp 00000000 08:02 68395554                           /lib/libachk.sof7740000-f7741000 r--p 00003000 08:02 68395554                           /lib/libachk.sof7741000-f7742000 rw-p 00004000 08:02 68395554                           /lib/libachk.sof777a000-f777c000 rw-p 00000000 00:00 0f777c000-f7784000 r-xp 00000000 08:02 68395441                           /lib/librt-2.11.3.sof7784000-f7785000 r--p 00007000 08:02 68395441                           /lib/librt-2.11.3.sof7785000-f7786000 rw-p 00008000 08:02 68395441                           /lib/librt-2.11.3.sof7786000-f779d000 r-xp 00000000 08:02 68395437                           /lib/libpthread-2.11.3.sof779d000-f779e000 r--p 00016000 08:02 68395437                           /lib/libpthread-2.11.3.sof779e000-f779f000 rw-p 00017000 08:02 68395437                           /lib/libpthread-2.11.3.sof779f000-f77a2000 rw-p 00000000 00:00 0f77a2000-f77a5000 r-xp 00000000 08:02 68395417                           /lib/libdl-2.11.3.sof77a5000-f77a6000 r--p 00002000 08:02 68395417                           /lib/libdl-2.11.3.sof77a6000-f77a7000 rw-p 00003000 08:02 68395417                           /lib/libdl-2.11.3.sof77a7000-f77a8000 r-xp 00000000 08:02 46924193                           /home/wutiejun/Temp/sotest/libhello.sof77a8000-f77a9000 r--p 00000000 08:02 46924193                           /home/wutiejun/Temp/sotest/libhello.sof77a9000-f77aa000 rw-p 00001000 08:02 46924193                           /home/wutiejun/Temp/sotest/libhello.sof77aa000-f77ab000 rw-p 00000000 00:00 0f77ab000-f77ca000 r-xp 00000000 08:02 68395404                           /lib/ld-2.11.3.sof77ca000-f77cb000 r--p 0001e000 08:02 68395404                           /lib/ld-2.11.3.sof77cb000-f77cc000 rw-p 0001f000 08:02 68395404                           /lib/ld-2.11.3.soffd99000-ffdba000 rw-p 00000000 00:00 0                                  [stack]ffffe000-fffff000 r-xp 00000000 00:00 0                                  [vdso]wutiejun@linux-00343520:~>