Bug 688980 (CVE-2011-1089) - CVE-2011-1089 glibc: Suid mount helpers fail to anticipate RLIMIT_FSIZE
Summary: CVE-2011-1089 glibc: Suid mount helpers fail to anticipate RLIMIT_FSIZE
Status: CLOSED ERRATA
Alias: CVE-2011-1089
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: public=20110303,reported=20110301,sou...
Keywords: Security
Depends On: 716899 716901 767685 767687 769360
Blocks: 734217 767564
TreeView+ depends on / blocked
 
Reported: 2011-03-18 17:50 UTC by Vincent Danen
Modified: 2019-06-08 18:46 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2012-02-13 20:57:09 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1526 normal SHIPPED_LIVE Low: glibc security, bug fix, and enhancement update 2011-12-06 01:02:21 UTC
Sourceware 12625 None None None Never
Red Hat Product Errata RHSA-2012:0125 normal SHIPPED_LIVE Moderate: glibc security and bug fix update 2012-02-14 01:33:53 UTC
Red Hat Product Errata RHSA-2012:0126 normal SHIPPED_LIVE Moderate: glibc security update 2012-02-14 01:33:37 UTC

Description Vincent Danen 2011-03-18 17:50:00 UTC
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 RLIMIT_FSIZE, 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 RLIMIT_FSIZE 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 my_addmntent(), 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

Comment 1 Tomas Hoger 2011-03-31 09:34:27 UTC
glibc bug for the addmntent() issue that causes it to not report error when output written to the file is truncated when hitting file size limit:
  http://sourceware.org/bugzilla/show_bug.cgi?id=12625

Comment 2 Vincent Danen 2011-04-12 21:55:31 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-1089 to
the following vulnerability:

Name: CVE-2011-1089
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1089
Assigned: 20110224
Reference: http://openwall.com/lists/oss-security/2011/03/04/9
Reference: http://sourceware.org/bugzilla/show_bug.cgi?id=12625
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=688980
Reference: http://www.securityfocus.com/bid/46740

The addmntent function in the GNU C Library (aka glibc or libc6) 2.13
and earlier does not report an error status for failed attempts to
write to the /etc/mtab file, which makes it easier for local users to
trigger corruption of this file, as demonstrated by writes from a
process with a small RLIMIT_FSIZE value, a different vulnerability
than CVE-2010-0296.

Comment 3 Vincent Danen 2011-04-12 22:30:45 UTC
MITRE assigned a number of CVEs to these issues; I've filed separate bugs for each one:

CVE-2011-1675 (bug #695916) mount fails to anticipate RLIMIT_FSIZE
CVE-2011-1676 (bug #695921) mount does not remove /etc/mtab.tmp after failed mount entry addition
CVE-2011-1677 (bug #695924) mount does not remove /etc/mtab~ lock file after failed mount entry addition
CVE-2011-1678 (bug #695925) mount.cifs and umount.cifs fail to anticipate RLIMIT_FSIZE
CVE-2011-1679 (bug #695927) ncpmount and ncpumount fail to anticipate RLIMIT_FSIZE
CVE-2011-1680 (bug #695932) ncpmount does not remove /etc/mtab~ lock file after failed mount entry addition

Comment 4 Tomas Hoger 2011-05-12 10:06:37 UTC
(In reply to comment #1)
> glibc bug for the addmntent() issue that causes it to not report error when
> output written to the file is truncated when hitting file size limit:
>   http://sourceware.org/bugzilla/show_bug.cgi?id=12625

Fix committed upstream now as:
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=e1fb097f447a89aa69a926e45e673a52d86a6c57

Comment 8 Murray McAllister 2011-11-15 05:28:58 UTC
Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.

Comment 9 errata-xmlrpc 2011-12-06 17:46:51 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:1526 https://rhn.redhat.com/errata/RHSA-2011-1526.html

Comment 13 errata-xmlrpc 2012-02-13 20:35:07 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2012:0126 https://rhn.redhat.com/errata/RHSA-2012-0126.html

Comment 14 errata-xmlrpc 2012-02-13 20:35:48 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2012:0125 https://rhn.redhat.com/errata/RHSA-2012-0125.html

Comment 15 Vincent Danen 2012-02-13 20:57:09 UTC
Statement:

(none)


Note You need to log in before you can comment on or make changes to this bug.