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.
Created samba tracking bugs for this issue Affects: fedora-all [bug 695942]
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.
(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).
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...
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.
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.
(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?
(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.
http://git.samba.org/?p=cifs-utils.git;a=commitdiff;h=f6eae44a3d05b6515a59651e6bed8b6dde689aec
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.
It has been fixed in f14, f15 and rawhide. See bug 695942.
(In reply to comment #16) > It has been fixed in f14, f15 and rawhide. See bug 695942. Oh, sorry, missed that. Thanks!
Acknowledgements: Red Hat would like to thank Dan Rosenberg for reporting this issue.
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
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
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
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.