It was found a use after free in glob function of glibc when expanding ~user.
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 */
/* 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 . 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 . 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));
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:
Glibc posix/glob.c implementation was synced with gnulib via commit:
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:
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?