GNU Libc current is affected by: Re-mapping current loaded libray with malicious ELF file. The impact is: In worst case attacker may elevate privileges. The component is: libld. The attack vector is: Attacker sends 2 ELF files to victim and asks to run ldd on it. ldd execute code. References: http://www.securityfocus.com/bid/109167 https://sourceware.org/bugzilla/show_bug.cgi?id=22851 https://support.f5.com/csp/article/K11932200?utm_source=f5support&utm_medium=RSS https://security-tracker.debian.org/tracker/CVE-2019-1010023
Created glibc tracking bugs for this issue: Affects: fedora-all [bug 1773917]
Please see https://sourceware.org/bugzilla/show_bug.cgi?id=22851#c1 : ldd is not intended to be executed on untrusted binaries, so this is not a security vulnerability.
The attack requires two ELF files: the first can be an executable or a library that depends on the second file, a library. When `ldd` is executed on the first file, it tries to load the malicious library but while doing so it executes code. An attacker may trick a victim user into executing `ldd` on the malicious files, thus executing code with his privileges.
glibc assumes loadable segment entries (PT_LOAD) in the program header table appear in ascending order, sorted on the p_vaddr member. While loading a library, function _dl_map_segments() in dl-map-segments.h lets the kernel map the first segment of the library anywhere it likes, but it requires a large enough chunk of memory to include all the loadable segment entries. Considering how mmap works, the allocation happens to be close to other libraries and to the ld-linux loader segments. However, if a library is created such that the first loadable segment entry is not the one with the lowest Virtual Address or the last loadable segment entry is not the one with the highest End Virtual Address, it is possible to make ld-linux wrongly compute the overall size required to load the library in the process' memory. When this happens, the malicious library can easily overwrite other libraries that were already loaded. While a malicious library can already easily execute code (e.g. with constructors) when a program uses it, it should not be possible to execute code while listing the dependencies of an ELF file.
Function _dl_map_segments() compute the required size to map the library at https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=elf/dl-load.c;h=6cdd11e6b0440a4123a404cc477053f7902910d6;hb=refs/heads/master#l1180 .
Statement: `ldd` is not intended to be executed on untrusted binaries, so a user should be very careful on what he runs `ldd` on.
Impact of the flaw set to Low as `ldd` should not be run on untrusted binaries and that is explicitly documented in its man page.
Mitigation: Use `objdump -p /path/to/program | grep NEEDED` instead of `ldd` when you want to get the library dependencies of an untrusted executable. However this just returns the direct dependencies of the program, so it should be manually run against all the needed libraries to get the entire dependency tree as `ldd` does.