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: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: 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
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

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
Statement:

`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
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.