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.
An integer 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 very long message, leading to an incorrect calculation of the buffer size to store the message, resulting in undefined behavior. This issue affects glibc 2.37 and newer.
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.
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.
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
Last updated 24 July 2024
Last updated 24 July 2024
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.
Last updated 24 July 2024
Last updated 24 July 2024
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 ...
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.
ld.so in the GNU C Library (aka glibc or libc6) before 2.11.3, and 2.12.x before 2.12.2, does not properly restrict use of the LDAUDIT environment variable to reference dynamic shared objects (DSOs) as audit objects, which allows local users to gain privileges by leveraging an unsafe DSO located in a trusted library directory, as demonstrated by libpcprofile.so.
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.
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.
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
ld.so in the GNU C Library (aka glibc or libc6) 2.13 and earlier expands the $ORIGIN dynamic string token when RPATH is composed entirely of this token, which might allow local users to gain privileges by creating a hard link in an arbitrary directory to a (1) setuid or (2) setgid program with this RPATH value, and then executing the program with a crafted value for the LDPRELOAD environment variable, a different vulnerability than CVE-2010-3847 and CVE-2011-0536. NOTE: it is not expected that any standard operating-system distribution would ship an applicable setuid or setgid program.
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.
Dan Rosenberg reported a flaw with suid mount helpers handle access to /etc/mtab [1], which could allow an unprivileged user to corrupt /etc/mtab and possibly manipulate mountpoint options or unmount a filesystem.
The original report follows.
This was originally sent to the now-defunct vendor-sec mailing list. Seeing how it's a relatively low-severity issue and that we're currently lacking a mechanism for coordination among package maintainers and vendors, this list seems like a perfectly acceptable venue for discussing how to fix it.
I discovered that essentially every suid mount helper that uses addmntent() (or invokes util-linux mount, which in turn calls addmntent()) to add entries to /etc/mtab fails to anticipate a low value for RLIMITFSIZE, allowing unprivileged users to corrupt /etc/mtab and possibly manipulate mountpoint options. Affected software includes at least:
mount.cifs (samba) fusermount (FUSE) mount (util-linux) ncpmount (ncpfs) vmware-hgfsmounter (open-vm-tools)
Also affected are all their unmount equivalents.
This can be exploited by checking the current size of /etc/mtab, setting an RLIMITFSIZE of some small amount greater than that, and invoking a suid mount helper. The edits to /etc/mtab will be truncated to the ulimit and no newline will be appended, so multiple invocations allow near-arbitrary appending to /etc/mtab. addmntent() will octal-encode most special characters, which makes exploitation beyond simple corruption not quite as straightforward, but I'm confident that with some creativity it would be possible to perform unauthorized unmounting, for example.
There are a few possible options We could patch glibc to try to raise the rlimit in addmntent(). Or we could fix every suid mount helper to raise the rlimit or have proper error handling for the case when addmntent() fails. This final option requires that mtab editing be done in a temporary file and aborted on failure, which isn't the case for all helpers.
Of course, once we figure out how to fix this, we can talk about assigning CVEs, etc.
And a followup regarding specific mount helpers:
I did a survey of some suid helpers I'm aware of. Here's the existing behavior:
util-linux mount ============= Edits /etc/mtab.tmp with custom myaddmntent(), behaves identically to glibc addmntent() in terms of return code Succeeds on partial writes, does not remove temp file on failure (could result in additional corruption of /etc/mtab through multiple invocations), does not remove lock file /etc/mtab~ on failure (also an issue)
fusermount (FUSE) ================ Does not edit mtab directly, calls into util-linux mount/umount, no changes needed
mount.cifs (samba) ================ mount.cifs edits /etc/mtab directly, no cleanup on addmntent() failure umount.cifs edits /etc/mtab.tmp but does not check return code of addmntent()
ncpmount (ncpfs) ============== ncpmount edits /etc/mtab directly, no cleanup on failure, does not remove lock file /etc/mtab~ on failure ncpumount edits /etc/mtab.tmp but does not check return code of addmntent()
vmware-hgfsmounter (open-vm-tools) =============================== edits /etc/mtab directly, no cleanup on failure
Further discussion is ongoing via the oss-security mailing list.
[1] http://thread.gmane.org/gmane.comp.security.oss.general/4374
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 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.
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