The deprecated functions nsprintrrf, nsprintrr and fpnquery in the GNU C Library version 2.2 and newer fail to enforce the caller-supplied buffer length, and can result in an out-of-bounds write when printing TSIG records.

A flaw was found in glibc. The getcwd() function is affected by an off-by-one buffer overflow and underflow that may lead to memory corruption when the size of the buffer is exactly 1 byte.

Last updated 24 July 2024

GNU C Library (aka glibc or libc6) is vulnerable to a denial of service, caused by an error when processing some invalid inputs from several IBM character sets in the iconv function. By sending invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, IBM1399 encodings, a local authenticated attacker could exploit this vulnerability to cause the application to enter into an infinite loop.

endpattern (called from internalfnmatch) in the GNU C Library (aka glibc or libc6) before 2.22 might allow context-dependent attackers to cause a denial of service (application crash), as demonstrated by use of the fnmatch library function with the (!() pattern. NOTE: this is not the same as CVE-2015-8984; also, some Linux distributions have fixed CVE-2015-8984 but have not fixed this additional fnmatch issue.

In the GNU C Library (aka glibc or libc6) through 2.29, the memcmp function for the x32 architecture can incorrectly return zero (indicating that the inputs are equal) because the RDX most significant bit is mishandled.

Last updated 24 July 2024

Certain run-time memory protection mechanisms in the GNU C Library (aka glibc or libc6) print argv[0] and backtrace information, which might allow context-dependent attackers to obtain sensitive information from process memory by executing an incorrect program, as demonstrated by a setuid program that contains a stack-based buffer overflow error, related to the fortifyfail function in debug/fortifyfail.c, and the stackchkfail (aka stack protection) and chkfail (aka FORTIFYSOURCE) implementations.

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

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.

elf/dl-load.c in ld.so in the GNU C Library (aka glibc or libc6) through 2.11.2, and 2.12.x through 2.12.1, does not properly handle a value of $ORIGIN for the LDAUDIT environment variable, which allows local users to gain privileges via a crafted dynamic shared object (DSO) located in an arbitrary directory.

It was reported [1] that scanf and related functions are crashing due to a bug [2] in glibc.

[1]: http://seclists.org/oss-sec/2015/q1/686 [2]: https://sourceware.org/bugzilla/showbug.cgi?id=13138

Integer overflow in posix/fnmatch.c in the GNU C Library (aka glibc or libc6) 2.13 and earlier allows context-dependent attackers to cause a denial of service (application crash) via a long UTF8 string that is used in an fnmatch call with a crafted pattern argument, a different vulnerability than CVE-2011-1071.

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

iconvdata/ibm930.c in GNU C Library (aka glibc) before 2.16 allows context-dependent attackers to cause a denial of service (out-of-bounds read) via a multibyte character value of "0xffff" to the iconv function when converting IBM930 encoded data to UTF-8.

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

A stack (frame) overflow flaw, leading to denial of service (application crash), was found in the way getaddrinfo() routine (returning a list of address structures for particular request) of glibc, the collection of GNU libc libraries, processed certain requests. If an application linked against glibc accepted untrusted getaddrinfo() input remotely, a remote attacker could issue a specially-crafted request, which once processed would lead to that application crash.

References: [1] https://bugzilla.novell.com/showbug.cgi?id=813121 [2] http://www.openwall.com/lists/oss-security/2013/04/03/2

Proposed Novell patch: [3] http://bugzillafiles.novell.org/attachment.cgi?id=533210

Buffer overflow in the extendbuffers function in the regular expression matcher (posix/regexec.c) in glibc, possibly 2.17 and earlier, allows context-dependent attackers to cause a denial of service (memory corruption and crash) via crafted multibyte characters.

DBLOOKUP in nssfiles/files-XXX.c in the Name Service Switch (NSS) in GNU C Library (aka glibc or libc6) 2.21 and earlier does not properly check if a file is open, which allows remote attackers to cause a denial of service (infinite loop) by performing a look-up on a database while iterating over it, which triggers the file pointer to be reset.

The wordexp function in GNU C Library (aka glibc) 2.21 does not enforce the WRDENOCMD flag, which allows context-dependent attackers to execute arbitrary commands, as demonstrated by input containing "$((...))".

GNU C Library (aka glibc) before 2.20 allows context-dependent attackers to cause a denial of service (out-of-bounds read and crash) via a multibyte character value of "0xffff" to the iconv function when converting (1) IBM933, (2) IBM935, (3) IBM937, (4) IBM939, or (5) IBM1364 encoded data to UTF-8.

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.

The popfailstack function in the GNU C Library (aka glibc or libc6) allows context-dependent attackers to cause a denial of service (assertion failure and application crash) via vectors related to extended regular expression processing.

A weakness in the dynamic loader has been found, making glibc of versions prior 2.22.90 affected. LDPOINTERGUARD in the environment is not sanitizaed allowing attacker to easily bypass the pointer guarding protection on set-user-ID and set-group-ID programs.

Reproducing steps available at:

http://hmarco.org/bugs/glibcptrmangleweakness.html

CVE request:

http://seclists.org/oss-sec/2015/q3/504

For historic reasons, inetaddr and inetaton accept trailing garbage. Some parsers rely on this (for example, libresolv when it parses “nameserver” directives in /etc/resolv.conf).

This causes problems because some applications assume that a successful parse as an IPv4 address means that the string consists of just an IPv4 address, and nothing more.

Glibc should add a check for trailing garbage and relegate the old behavior to a compatibility symbol.

For backporting, glibc should just fix getaddrinfo (and related functions if necessary) so that they will not accept trailing garbage.

Upstream bug : https://sourceware.org/bugzilla/showbug.cgi?id=20018

Additional note : When used in combination with flaw described in CVE-2016-5699, an attacker could direct an HTTP connection to a malicious server, using the following combined issues:

Python's httplib does not validate HTTP header values. A malicious 'Host' header with quoted new lines can inject additional headers and more glibc's getaddrinfo() ignores new lines and everything after a new line character when the first part looks like a IPv4 address

See the following blog post for additional information: http://blog.blindspotsecurity.com/2016/06/advisory-http-header-injection-in.html

A flaw was found in glibc. The realpath function may sometimes return a unexpected value, potentially leading to disclosure of sensitive data.

A security flaw was found in the way ptchown, a helper function for grantpt(3) to change ownership and permissions of pseudoterminal, of glibc, the collection of GNU libc libraries, performed pseudotty ownership and permission changes when granting access to the slave pseudoterminal. A local attacker could use this flaw to obtain unauthorized read / write access at the pseudoterminal of their choose by using a specially-crafted (by attacker supplied) file system.

Acknowledgements:

Red Hat would like to thank Martin Carpenter of Citco for reporting this issue.

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