Bug 695925 (CVE-2011-1678) - CVE-2011-1678 samba/cifs-utils: mount.cifs and umount.cifs fail to anticipate RLIMIT_FSIZE
Summary: CVE-2011-1678 samba/cifs-utils: mount.cifs and umount.cifs fail to anticipate...
Status: CLOSED ERRATA
Alias: CVE-2011-1678
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact: Jian Li
URL:
Whiteboard: public=20110303,reported=20110301,sou...
Keywords: Security
Depends On: 695942 722551 722552 722553 722555 722556 725508 725509
Blocks: 721358
TreeView+ depends on / blocked
 
Reported: 2011-04-12 22:20 UTC by Vincent Danen
Modified: 2015-07-31 06:39 UTC (History)
9 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-08-30 07:22:21 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1219 normal SHIPPED_LIVE Moderate: samba security update 2011-08-29 17:27:40 UTC
Red Hat Product Errata RHSA-2011:1220 normal SHIPPED_LIVE Moderate: samba3x security update 2011-08-29 17:27:16 UTC
Red Hat Product Errata RHSA-2011:1221 normal SHIPPED_LIVE Moderate: samba and cifs-utils security and bug fix update 2011-08-29 17:38:17 UTC

Description Vincent Danen 2011-04-12 22:20:22 UTC
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 22:38:16 UTC
Created samba tracking bugs for this issue

Affects: fedora-all [bug 695942]

Comment 2 Jeff Layton 2011-04-13 00:06:42 UTC
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 08:01:21 UTC
(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 13:29:29 UTC
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 13:54:57 UTC
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 14:09:05 UTC
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 14:32:41 UTC
(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 15:11:43 UTC
(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 21:13:09 UTC
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-27 00:03:12 UTC
It has been fixed in f14, f15 and rawhide. See bug 695942.

Comment 18 Vincent Danen 2011-07-27 19:23:07 UTC
(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-04 01:46:38 UTC
Acknowledgements:

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

Comment 20 errata-xmlrpc 2011-08-29 17:27:28 UTC
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 17:28:00 UTC
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 17:38:27 UTC
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 19:24:12 UTC
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.