A stack overflow vulnerability in the catopen function was found, causing applications which pass long strings to the catopen function to crash or, potentially execute arbitrary code.

Upstream bug:

https://sourceware.org/bugzilla/showbug.cgi?id=17905

CVE assignment:

http://seclists.org/oss-sec/2016/q1/153

An integer overflow vulnerability was found in hcreate and hcreater which can result in an out-of-bound memory access. This could lead to application crashes or, potentially, arbitrary code execution.

Upstream bug:

https://sourceware.org/bugzilla/showbug.cgi?id=18240

CVE assignment:

http://seclists.org/oss-sec/2016/q1/153

Last updated 24 July 2024

It was found that out-of-range time values passed to the strftime function may cause it to crash, leading to a denial of service, or potentially disclosure information.

Upstream bug:

https://sourceware.org/bugzilla/showbug.cgi?id=18985

CVE assignment:

http://seclists.org/oss-sec/2016/q1/153

A heap-based buffer overflow was found in the vsysloginternal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when the openlog function was not called, or called with the ident argument set to NULL, and the program name (the basename of argv[0]) is bigger than 1024 bytes, resulting in an application crash or local privilege escalation. This issue affects glibc 2.36 and newer.

ptchown in the glibc package before 2.19-18+deb8u4 on Debian jessie; the elibc package before 2.15-0ubuntu10.14 on Ubuntu 12.04 LTS and before 2.19-0ubuntu6.8 on Ubuntu 14.04 LTS; and the glibc package before 2.21-0ubuntu4.2 on Ubuntu 15.10 and before 2.23-0ubuntu1 on Ubuntu 16.04 LTS and 16.10 lacks a namespace check associated with file-descriptor passing, which allows local users to capture keystrokes and spoof data, and possibly gain privileges, via pts read and write operations, related to debian/sysdeps/linux.mk. NOTE: this is not considered a vulnerability in the upstream GNU C Library because the upstream documentation has a clear security recommendation against the --enable-ptchown option.

An off-by-one heap-based buffer overflow was found in the vsysloginternal function of the glibc library. This function is called by the syslog and vsyslog functions. This issue occurs when these functions are called with a message bigger than INTMAX bytes, leading to an incorrect calculation of the buffer size to store the message, resulting in an application crash. This issue affects glibc 2.37 and newer.

Integer overflow in the strxfrm function in the GNU C Library (aka glibc or libc6) before 2.21 allows context-dependent attackers to cause a denial of service (crash) or possibly execute arbitrary code via a long string, which triggers a stack-based buffer overflow.

Integer overflow in the IOwstroverflow function in libio/wstrops.c ...

A flaw was found in the way memory was being allocated on the stack for user space binaries. If heap and stack memory regions were adjacent to each other, an attacker could use this flaw to jump over the heap/stack gap, cause controlled memory corruption on process stack or heap, and thus increase their privileges on the system.

This is a tracking bug for the glibc part of the mitigation.

A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBCTUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBCTUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.

It was reported [1] that getnetbyname function in glibc 2.21 in earlier will enter an infinite loop if the DNS backend is activated in the system Name Service Switch configuration, and the DNS resolver receives a positive answer while processing the network name.

Upstream commit that fixes this issue: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=11e3417af6e354f1942c68a271ae51e892b2814d

[1]: https://sourceware.org/bugzilla/showbug.cgi?id=17630

DISPUTED The xdrbytes and xdrstring functions in the GNU C Library (aka glibc or libc6) 2.25 mishandle failures of buffer deserialization, which allows remote attackers to cause a denial of service (virtual memory allocation, or memory consumption if an overcommit setting is not used) via a crafted UDP packet to port 111, a related issue to CVE-2017-8779. NOTE: [Information provided from upstream and references]

An issue was discovered in the GNU C Library (glibc) 2.36. When the syslog function is passed a crafted input string larger than 1024 bytes, it reads uninitialized memory from the heap and prints it to the target log file, potentially revealing a portion of the contents of the heap.

Off-by-one error in the gconvtranslitfind function in gconvtrans.c in GNU C Library (aka glibc) allows context-dependent attackers to cause a denial of service (crash) or execute arbitrary code via vectors related to the CHARSET environment variable and gconv transliteration modules.

nis/nssnis/nis-pwd.c in the GNU C Library (aka glibc or libc6) 2.7 and Embedded GLIBC (EGLIBC) 2.10.2 adds information from the passwd.adjunct.byname map to entries in the passwd map, which allows remote attackers to obtain the encrypted passwords of NIS accounts by calling the getpwnam function.

Last updated 24 July 2024

Last updated 24 July 2024

Stack-based buffer overflow in the nssdns implementation of the getnetbyname function in GNU C Library (aka glibc) before 2.24 allows context-dependent attackers to cause a denial of service (stack consumption and application crash) via a long name.

In the GNU C Library (aka glibc or libc6) through 2.29, checkdstlimitscalcpos1 in posix/regexec.c has Uncontrolled Recursion, as demonstrated by '(\227|)(\\1\\1|t1|\\\2537)+' in grep.

It was discovered that the nssfiles backend for the Name Service Switch in glibc would return incorrect data to applications or corrupt the heap (depending on adjacent heap contents), potentially resulting in arbitrary code execution.

A flaw was found in the way memory was being allocated on the stack for user space binaries. If heap and stack memory regions were adjacent to each other, an attacker could use this flaw to jump over the heap/stack gap, cause controlled memory corruption on process stack or heap, and thus increase their privileges on the system.

This is a tracking bug for the glibc part of the mitigation.

It was discovered that the nssfiles backend for the Name Service Switch in glibc would return incorrect data to applications or corrupt the heap (depending on adjacent heap contents), potentially resulting in arbitrary code execution.

A buffer underflow in realpath() in glibc when getcwd() returns relative path or unreachable path (i.e. not starting with '/') was found that can allow privilege escalation under certain conditions.

Reference:

http://www.openwall.com/lists/oss-security/2018/01/11/5

DISPUTED ldd in the GNU C Library (aka glibc or libc6) 2.13 and earlier allows local users to gain privileges via a Trojan horse executable file linked with a modified loader that omits certain LDTRACELOADEDOBJECTS checks. NOTE: the GNU C Library vendor states "This is just nonsense. There are a gazillion other ways to introduce code if people are downloading arbitrary binaries and install them in appropriate directories or set LDLIBRARYPATH etc."

In the Phrack article "A Eulogy for Format Strings", a researcher using nickname "Captain Planet" reported an integer overflow flaw in the format string protection mechanism offered by FORTIFYSOURCE. A remote attacker could provide a specially crafted executable, leading to FORTIFYSOURCE format string protection mechanism bypass, when executed.

References: http://www.phrack.org/issues.html?issue=67&id=9#article

Upstream bug and Kees Cook's proposed patches: http://sourceware.org/bugzilla/showbug.cgi?id=13656 http://sourceware.org/ml/libc-alpha/2012-02/msg00023.html http://sourceware.org/ml/libc-alpha/2012-02/msg00012.html http://sourceware.org/ml/libc-alpha/2012-02/msg00073.html

An out-of buffer bounds write flaw was found in the way the readdirr function in glibc, the GNU C Library, handled a directory entry whose file name name contained more byte than the NAMEMAX characters constant indicated. An attacker could provide a specially-crafted (local) NTFS or (remote) CIFS file system that, when processed in an application using the readdirr() function, would cause that application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.

Upstream bug report: [1] http://sourceware.org/bugzilla/showbug.cgi?id=14699

Latest patch proposal: [2] http://sourceware.org/ml/libc-alpha/2013-05/msg00445.html

Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC, (2) LANG, or other locale environment variable.

Integer overflow in the tzfileread function in glibc before 2.15 allows context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted timezone (TZ) file, as demonstrated using vsftpd.

Harald van Dijk discovered [1],[2] that glibc's locale command does not sufficiently sanitize the user environment. According to POSIX specifications [3], the output of the 'locale' command must be appropriately quoted and safe to execute, in order to restore the locale after temporarily forcing a change (such as LCALL=C). However, this is not the case with glibc versions up to and including 2.12.1:

LANG=' rm -rf /' locale locale: Cannot set LCCTYPE to default locale: No such file or directory locale: Cannot set LCMESSAGES to default locale: No such file or directory locale: Cannot set LCALL to default locale: No such file or directory LANG= rm -rf / LCCTYPE=" rm -rf /" LCNUMERIC=" rm -rf /" LCTIME=" rm -rf /" LCCOLLATE=" rm -rf /" LCMONETARY=" rm -rf /" LCMESSAGES=" rm -rf /" LCPAPER=" rm -rf /" LCNAME=" rm -rf /" LCADDRESS=" rm -rf /" LCTELEPHONE=" rm -rf /" LCMEASUREMENT=" rm -rf /" LCIDENTIFICATION=" rm -rf /" LCALL=

Any script that does "eval $(locale)" or something similar will execute the unquoted commands.

The POSIX specification states:

"The <value> and <implied value> shown above shall be properly quoted for possible later reentry to the shell. The <value> shall not be quoted using double-quotes (so that it can be distinguished by the user from the <implied value> case, which always requires double-quotes)."

This has been corrected upstream [4].

[1] http://bugs.gentoo.org/showbug.cgi?id=330923 [2] http://sources.redhat.com/bugzilla/showbug.cgi?id=11904 [3] http://www.opengroup.org/onlinepubs/000095399/utilities/locale.html [4] http://sourceware.org/git/?p=glibc.git;a=patch;h=026373745eab50a683536d950cb7e17dc98c4259