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
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-1752
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1811586 1813398 1814776 1815199 1815200 1815201
Blocks: 1810721
TreeView+ depends on / blocked
 
Reported: 2020-03-05 19:07 UTC by Guilherme de Almeida Suckevicz
Modified: 2023-10-06 19:21 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:
Environment:
Last Closed: 2020-11-04 02:24:39 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4444 0 None None None 2020-11-04 01:00:36 UTC
Sourceware 25414 0 P2 RESOLVED 'glob' use-after-free bug (CVE-2020-1752) 2020-11-04 13:03:48 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.

Reference:
https://sourceware.org/bugzilla/show_bug.cgi?id=25414

Upstream commit:
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ddc650e9b3dc916eab417ce9f79e67337b05035c

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 */
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));
}
```

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

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

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?

Comment 14 errata-xmlrpc 2020-11-04 01:00:51 UTC
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

Comment 15 Product Security DevOps Team 2020-11-04 02:24:39 UTC
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


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