Summary: | ldd should protect against programs whose segments overlap with the loader itself | ||
---|---|---|---|
Product: | glibc | Reporter: | Ilya Smith <blackzert> |
Component: | dynamic-link | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | NEW --- | ||
Severity: | normal | CC: | blackzert, carlos, fweimer, ppluzhnikov, rschiron, rwmacleod, xiezhipeng1 |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2018-02-19 00:00:00 |
Description
Ilya Smith
2018-02-16 12:09:26 UTC
Thanks for reporting this. ldd is not intended to be executed on untrusted binaries, so this is not a security vulnerability. This is not the only issue with ldd. Bug 20857 demonstrates that the initial file mapping (and not just PT_LOAD segments) can override the dynamic linker. (The PT_LOAD approach discussed here works reliably because the kernel does not independently randomize the address of file mappings, even without MAP_FIXED.) 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. (In reply to Ilya Smith from comment #2) > And all these examples are about security. And this bug is also about > security. The dynamic loader assumes all binaries on disk are trusted. Therefore the issue is a hardening feature (from the perspective of the glibc project) for using untrusted binaries and must be balanced against performance. At present we do nothing to harden the loader against untrusted binaries. To inspect untrusted binaries you must use libelf or libbfd. Therefore this is marked security-, it is not a security issue. > If attacker can ask ld library to load special crafted ELF file it can get code execution
It seems to me that creating a specially crafted ELF is a complicated way to achieve what can be *trivially* achieved by creating a DSO with an initializer (DT_INIT).
If you can ask for "random" DSO to be loaded, then that DSO's initializer can do *anything*, and you've already lost.
I think this bug should be closed as invalid.
(In reply to Paul Pluzhnikov from comment #4) > > If attacker can ask ld library to load special crafted ELF file it can get code execution > > It seems to me that creating a specially crafted ELF is a complicated way to > achieve what can be *trivially* achieved by creating a DSO with an > initializer (DT_INIT). > > If you can ask for "random" DSO to be loaded, then that DSO's initializer > can do *anything*, and you've already lost. > > I think this bug should be closed as invalid. This case just an example, you never know how exactly it will be used. DSO's initialisers could be checked since everyone knows about it. This bug is not invalid, since it is exists in the code and works as described. You can not reject reality. You may say "Risks of the bug exploitation are very low" and I agree. But you can't say "there is no bug". Copying from https://bugzilla.redhat.com/show_bug.cgi?id=1773916#c4 from completeness: 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. Hi, how about this patch? It will return error when loading invalid segments. https://sourceware.org/ml/libc-alpha/2020-02/msg00113.html (In reply to Zhipeng Xie from comment #8) > Hi, how about this patch? It will return error when loading invalid segments. > > https://sourceware.org/ml/libc-alpha/2020-02/msg00113.html Please see my thoughts here: https://www.sourceware.org/ml/libc-alpha/2019-12/msg00634.html https://www.sourceware.org/ml/libc-alpha/2020-02/msg00385.html I don't think the proposed patches are correct, sorry. |