[Bug dynamic-link/22851] ld library ELF load error

["blackzert at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22851

--- Comment #2 from Ilya Smith <blackzert at gmail dot com> ---
Hello,

This bug is about bad parsing of ELF files, but not about position-dependent
executables.

The problem of https://sourceware.org/bugzilla/show_bug.cgi?id=20857 is
Constantly-defined address from ELF file header used to re-mmap existing
segments (libc in this case). This is attended more to kernel behaviour and
mmap itself, that allows to re-mmap existing mapping. Good description of this
problem could be found here: https://lwn.net/Articles/741335/
And this bug hopefully would be fixed when MAP_FIXED_SAFE will by applied. And
libc should also support this flag as well.

This bug is about how ld parse ELF file segments - it doesn't check order of
segments and compute total size of ELF file wrong in some cases. Exploiting ldd
is just an example of it and it has security impact.

As you said, ldd not intended to run untrusted files. But intended is not the
same as prohibited. 

ldd will never ask's you if you sure what are you doing.

Here http://man7.org/linux/man-pages/man1/ldd.1.html it is said about security
of ldd:
 Security
       Be aware that in some circumstances (e.g., where the program speci‐
       fies an ELF interpreter other than ld-linux.so), some versions of ldd
       may attempt to obtain the dependency information by attempting to
       directly execute the program, which may lead to the execution of
       whatever code is defined in the program's ELF interpreter, and per‐
       haps to execution of the program itself.  (In glibc versions before
       2.27, the upstream ldd implementation did this for example, although
       most distributions provided a modified version that did not.)

That leaves a reasonable question - does 2.27 version of libc checks
interpreter name? If yes, is it safe? No, because libld can't parse ELF file's
properly.

ldd exploit is one of impacts. Here is another impacts:
• Obfuscation or anti-emulation:
  - Remapping the current ELF segment by the next loaded library
  - Code executed not only from the library entry point, constructors, or
export functions
• Cheating with binary-analysis tools: 
  - rabin2 from radare2 crashed calling dlopen
• Maybe more?

And all these examples are about security. And this bug is also about security.

-- 
You are receiving this mail because:
You are on the CC list for the bug.