Bug 1810718 (CVE-2020-1752)
Summary: | CVE-2020-1752 glibc: use-after-free in glob() function when expanding ~user | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Guilherme de Almeida Suckevicz <gsuckevi> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | unspecified | CC: | aoliva, arjun.is, ashankar, bdettelb, codonell, dj, fweimer, glibc-bugzilla, law, lmorse, mcascell, mfabian, mnewsome, pfrankli, rth, security-response-team, siddhesh |
Target Milestone: | --- | Keywords: | Security |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | glibc 2.32 | Doc Type: | If docs needed, set a value |
Doc Text: |
A use-after-free vulnerability was found in glibc in the way the tilde expansion was carried out. Directory paths containing an initial tilde followed by a valid username were affected by this issue. A local attacker could exploit this flaw by creating a specially crafted path that, when processed by the glob function, would potentially lead to arbitrary code execution.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2020-11-04 02:24:39 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: | 1811586, 1813398, 1814776, 1815199, 1815200, 1815201 | ||
Bug Blocks: | 1810721 |
Description
Guilherme de Almeida Suckevicz
2020-03-05 19:07:38 UTC
Created glibc tracking bugs for this issue: Affects: fedora-all [bug 1811586] Both glibc and gnulib share the same vulnerable code in glob.c. Generally speaking, function glob_use_alloca() is used to determine whether an object can be allocated on the stack or not: ``` if (glob_use_alloca(alloca_used, size)) /* use stack */ else /* use malloc */ ``` glob_use_alloca() leverages __libc_use_alloca() to implement the actual check. The key difference between gnulib and glibc revolves around the definition of __libc_use_alloca(). In gnulib the previous check is never satisfied, as __libc_use_alloca() turns out to always be false in glob.c [1]. As a result, the directory path ends up being allocated on the heap via malloc() and it may be possible for an attacker to exploit the use-after-free vulnerability. Glibc honors glob_use_alloca() in the same way as above. However, glibc includes the Native POSIX Thread Library (NPTL) which provides a concrete definition for __libc_use_alloca() in sysdeps/pthread/allocalim.h [2]. In glibc the stack is used most of the time, as the above check is likely to be satisfied. In order to exploit this flaw on glibc, an attacker would have to force the use of malloc() instead of the stack, possibly by providing a huge directory path. [1] GNULIB ``` /* Just use malloc. */ # define __libc_use_alloca(n) false ``` [2] GLIBC ``` int __libc_use_alloca (size_t size) { return (__glibc_likely (__libc_alloca_cutoff (size)) || __glibc_likely (size <= PTHREAD_STACK_MIN / 4)); } ``` In reply to comment #7: > as __libc_use_alloca() turns out to always be false in glob.c Macro __libc_use_alloca() was defined to be false in gnulib via commit: -> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=36cc6c33ade715a844662cefd256f8f8fdd8a05d Glibc posix/glob.c implementation was synced with gnulib via commit: -> https://sourceware.org/git/?p=glibc.git;a=commit;h=c66c908230169c1bab1f83b071eb585baa214b9f Statement: The Red Hat Product Security Team has rated this issue as having Moderate security impact. This flaw did not affect the versions of `glibc` as shipped with Red Hat Enterprise Linux 5 and 6, as the vulnerable code was introduced in a later version of the package. Red Hat Enterprise Linux 7 is approaching the End of Maintenance Support 1 Phase of the support and maintenance life cycle. The flaw is not currently planned to be addressed in future updates of Red Hat Enterprise Linux 7, hence marked as "Will not fix". For further information, please refer to the Red Hat Enterprise Linux Life Cycle and Issue Severity Classification: [1] https://access.redhat.com/support/policy/updates/errata [2] https://access.redhat.com/security/updates/classification Mitigation: Avoid the expansion of overly long directory paths. We outstanding issues CVE-2020-10029 and CVE-2020-1752, but there is no new errata for these. Do you all have an ETA for the glibc fix for RHEL 8? This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:4444 https://access.redhat.com/errata/RHSA-2020:4444 This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-1752 |