This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 695925 - (CVE-2011-1678) CVE-2011-1678 samba/cifs-utils: mount.cifs and umount.cifs fail to anticipate RLIMIT_FSIZE
CVE-2011-1678 samba/cifs-utils: mount.cifs and umount.cifs fail to anticipate...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
Jian Li
public=20110303,reported=20110301,sou...
: Security
Depends On: 695942 722551 722552 722553 722555 722556 725508 725509
Blocks: 721358
  Show dependency treegraph
 
Reported: 2011-04-12 18:20 EDT by Vincent Danen
Modified: 2015-07-31 02:39 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-30 03:22:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2011-04-12 18:20:22 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-1678 tothe following vulnerability:

Name: CVE-2011-1678
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1678
Assigned: 20110409
Reference: http://openwall.com/lists/oss-security/2011/03/04/9
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=688980

smbfs in Samba 3.5.8 and earlier attempts to use (1) mount.cifs to
append to the /etc/mtab file and (2) umount.cifs to append to the
/etc/mtab.tmp file without first checking whether resource limits
would interfere, which allows local users to trigger corruption of the
/etc/mtab file via a process with a small RLIMIT_FSIZE value, a
related issue to CVE-2011-1089.
Comment 1 Vincent Danen 2011-04-12 18:38:16 EDT
Created samba tracking bugs for this issue

Affects: fedora-all [bug 695942]
Comment 2 Jeff Layton 2011-04-12 20:06:42 EDT
Certainly sounds like a bug worth fixing but I don't see it as a true vulnerability for Fedora or RHEL as we don't ship these as setuid programs. Is there something I'm missing?

Also, mount.cifs and umount.cifs have not shipped as part of samba for well over a year now, so this should probably be marked as a cifs-utils bug.
Comment 3 Tomas Hoger 2011-04-13 04:01:21 EDT
(In reply to comment #2)
> Certainly sounds like a bug worth fixing but I don't see it as a true
> vulnerability for Fedora or RHEL as we don't ship these as setuid programs. Is
> there something I'm missing?

No, that's correct.  This is not much of an issue unless mount.cifs is setuid.

> Also, mount.cifs and umount.cifs have not shipped as part of samba for well
> over a year now, so this should probably be marked as a cifs-utils bug.

Thank you, info corrected.  It's still going to list samba for older distributions that don't have separate cifs-utils (RHEL-4 and RHEL-5).
Comment 4 Jeff Layton 2011-04-13 09:29:29 EDT
Ok, cool. I still think the most appropriate place to fix this would be in glibc...

mount helpers like mount.cifs usually just call addmntent, and pass in a struct mntent pointer with the proper fields. glibc then takes that and formats the string that it writes to the file.

Until that point, you can only guess how big the resulting string will actually be, as you don't necessarily know how big the delimiters will be. glibc mostly seems to use single spaces, but what if they change it to use more than one at some point? The only way to know for sure is to check after you format the string, and at that point you're in glibc territory...
Comment 5 Tomas Hoger 2011-04-13 09:54:57 EDT
What would be your proposal for proposal for glibc-side fix?  fstat file and check if formatted string fits into (RLIMIT_FSIZE - stat.st_size) before trying to write to the file?  There was a proposal to make glibc adjust FSIZE limit, but that was rejected:

http://thread.gmane.org/gmane.comp.security.oss.general/4374/focus=4487

FSIZE limit check also may not do the trick in all error cases I suspect (e.g. ENOSPC).

The thread also pointed out that glibc addmntent did not always return error when expected - see bug #688980, comment #1.
Comment 6 Jeff Layton 2011-04-13 10:09:05 EDT
Yes, that's more or less what I was thinking. Check to make sure that you're not going to run afoul of RLIMIT_FSIZE before you do the write.

Another idea might be to truncate the file back to its original size if the write isn't completely successful, and then return an error on the addmntent call.

There's still a window where the file would be corrupt, but maybe that's good enough. It might also be reasonable to have these routines build the new file in a tempfile and then rename it on top of /etc/mtab.

I think though if glibc has a hard time getting this right then it's pretty unreasonable to expect the mount helpers to work around those limitations.
Comment 8 Tomas Hoger 2011-04-21 10:32:41 EDT
(In reply to comment #6)

> There's still a window where the file would be corrupt, but maybe that's good
> enough. It might also be reasonable to have these routines build the new file
> in a tempfile and then rename it on top of /etc/mtab.
> 
> I think though if glibc has a hard time getting this right then it's pretty
> unreasonable to expect the mount helpers to work around those limitations.

I'd say libc *mntent set of interfaces does not seem to attempt to provide a safe way to edit mtab file using intermediate temporary file and leaves it mounters to handle that.

It might make sense to make all mounters use compatible "locking" to avoid corruptions on simultaneous write.  Is this really worth it given the efforts to obsolete mtab completely?
Comment 9 Jeff Layton 2011-04-21 11:11:43 EDT
(In reply to comment #8)
>
> I'd say libc *mntent set of interfaces does not seem to attempt to provide a
> safe way to edit mtab file using intermediate temporary file and leaves it
> mounters to handle that.
> 

Fair enough. That's probably what it'll take to fix this (building a replacement mtab in a temp location and renaming it into place).

> It might make sense to make all mounters use compatible "locking" to avoid
> corruptions on simultaneous write.  Is this really worth it given the efforts
> to obsolete mtab completely?
>

Getting locking right was one of the intended purposes of libmount. mount.cifs at least uses the same scheme that's in /bin/mount so there shouldn't be conflicts there. Other mount helpers don't necessarily do this correctly however. I agree that we shouldn't expend a lot of effort on this though.
Comment 15 Vincent Danen 2011-07-26 17:13:09 EDT
I'm presuming this has not been fixed in cifs-utils in Fedora, or has it?  I can't see anything relevant in the changelog for cifs-utils.
Comment 16 Jeff Layton 2011-07-26 20:03:12 EDT
It has been fixed in f14, f15 and rawhide. See bug 695942.
Comment 18 Vincent Danen 2011-07-27 15:23:07 EDT
(In reply to comment #16)
> It has been fixed in f14, f15 and rawhide. See bug 695942.

Oh, sorry, missed that.  Thanks!
Comment 19 Murray McAllister 2011-08-03 21:46:38 EDT
Acknowledgements:

Red Hat would like to thank Dan Rosenberg for reporting this issue.
Comment 20 errata-xmlrpc 2011-08-29 13:27:28 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:1220 https://rhn.redhat.com/errata/RHSA-2011-1220.html
Comment 21 errata-xmlrpc 2011-08-29 13:28:00 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2011:1219 https://rhn.redhat.com/errata/RHSA-2011-1219.html
Comment 22 errata-xmlrpc 2011-08-29 13:38:27 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:1221 https://rhn.redhat.com/errata/RHSA-2011-1221.html
Comment 23 Vincent Danen 2011-08-29 15:24:12 EDT
Statement:

On Red Hat Enterprise Linux, by default, mount.cifs is not provided with the setuid bit enabled. If a user has turned on the setuid bit (via chmod +s /sbin/mount.cifs), they would be affected by this issue, and can work around the problem by removing the setuid bit.                                                                            

Red Hat Enterprise Linux 3 does not provide the mount.cifs program.

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