Bug 1810718 (CVE-2020-1752) - CVE-2020-1752 glibc: use-after-free in glob() function when expanding ~user
Summary: CVE-2020-1752 glibc: use-after-free in glob() function when expanding ~user
Status: NEW
Alias: CVE-2020-1752
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1813398 1815199 1815200 1815201 1811586 1814776
Blocks: 1810721
TreeView+ depends on / blocked
Reported: 2020-03-05 19:07 UTC by Guilherme de Almeida Suckevicz
Modified: 2020-08-21 21:32 UTC (History)
17 users (show)

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.
Clone Of:
Last Closed:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Sourceware 25414 P2 RESOLVED 'glob' use-after-free bug (CVE-2020-1752) 2020-09-15 13:32:56 UTC

Description Guilherme de Almeida Suckevicz 2020-03-05 19:07:38 UTC
It was found a use after free in glob function of glibc when expanding ~user.


Upstream commit:

Comment 1 Michael Kaplan 2020-03-09 10:01:20 UTC
Created glibc tracking bugs for this issue:

Affects: fedora-all [bug 1811586]

Comment 7 Mauro Matteo Cascella 2020-03-20 08:33:58 UTC
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 */
    /* 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.

/* Just use malloc. */
# define __libc_use_alloca(n) false

int __libc_use_alloca (size_t size)
    return (__glibc_likely (__libc_alloca_cutoff (size))
            || __glibc_likely (size <= PTHREAD_STACK_MIN / 4));

Comment 8 Mauro Matteo Cascella 2020-03-20 08:56:50 UTC
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

Comment 10 Mauro Matteo Cascella 2020-05-15 16:26:22 UTC

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

Comment 11 Mauro Matteo Cascella 2020-05-15 16:26:25 UTC

Avoid the expansion of overly long directory paths.

Comment 13 Laurie Morse 2020-06-28 17:59:38 UTC
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?

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