Last updated 24 July 2024

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.

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

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.

IssueDescription:

The "files" backend for the Name Service Switch (NSS) in glibc does not properly isolate iteration over the entire database from key-based lookups. As a result, an application which performs lookups on a database while iterating over it could enter an infinite loop, leading to a denial of service.

Acknowledgements:

This issue was discovered by Robin Hack of Red Hat.

It was reported [1] that glibc had a bug where it would use alloca() for the length of a user-supplied UTF8 string, times four (with additional integer overflow in the times four). This could lead to an application crash, because alloca() extends the stack.

This was reported upstream [2] and subsequently fixed upstream [3].

References:

[1] http://scarybeastsecurity.blogspot.com/2011/02/i-got-accidental-code-execution-via.html [2] http://sourceware.org/bugzilla/showbug.cgi?id=11883 [3] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f15ce4d8dc139523fe0c273580b604b2453acba6

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

It was discovered that the glibc DNS resolver dereferenced a NULL pointer when processing a specific, but valid resource record type.

Acknowledgements:

Name: Florian Weimer (Red Hat Product Security)

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

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