Bug 1773916 (CVE-2019-1010023) - CVE-2019-1010023 glibc: running ldd on malicious ELF leads to code execution because of wrong size computation
Summary: CVE-2019-1010023 glibc: running ldd on malicious ELF leads to code execution ...
Status: NEW
Alias: CVE-2019-1010023
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1773917 1775207 1775208
Blocks: 1773918
TreeView+ depends on / blocked
Reported: 2019-11-19 10:31 UTC by msiddiqu
Modified: 2019-12-17 03:07 UTC (History)
16 users (show)

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.
Clone Of:
Last Closed: 2019-11-19 11:12:04 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Sourceware 22851 P2 NEW ld library ELF load error 2020-01-29 17:58:52 UTC

Description msiddiqu 2019-11-19 10:31:51 UTC
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.


Comment 1 msiddiqu 2019-11-19 10:32:42 UTC
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1773917]

Comment 2 Florian Weimer 2019-11-19 11:12:04 UTC
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.

Comment 3 Riccardo Schirone 2019-11-21 10:49:20 UTC
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.

Comment 4 Riccardo Schirone 2019-11-21 14:27:09 UTC
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.

Comment 5 Riccardo Schirone 2019-11-21 14:31:12 UTC
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 .

Comment 6 Riccardo Schirone 2019-11-21 14:35:18 UTC

`ldd` is not intended to be executed on untrusted binaries, so a user should be very careful on what he runs `ldd` on.

Comment 7 Riccardo Schirone 2019-11-21 14:39:02 UTC
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.

Comment 8 Riccardo Schirone 2019-11-21 14:40:43 UTC

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.

Note You need to log in before you can comment on or make changes to this bug.