Bug 1773916 (CVE-2019-1010023)
Summary: | CVE-2019-1010023 glibc: running ldd on malicious ELF leads to code execution because of wrong size computation | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | msiddiqu |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | arjun.is, ashankar, bdettelb, codonell, dj, fweimer, glibc-bugzilla, law, mfabian, mnewsome, pfrankli, rschiron, security-response-team, siddhesh, sipoyare |
Target Milestone: | --- | Keywords: | Reopened, Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: |
It was discovered that when executing `ldd` on a malicious file, it is possible to execute code because of the way libraries are loaded into the process memory. An attacker may trick a victim user into running `ldd` on malicious files, thus executing code with their privileges.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2021-02-24 08:27:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1773917, 1775207, 1775208 | ||
Bug Blocks: | 1773918 |
Description
msiddiqu
2019-11-19 10:31:51 UTC
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. |