Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikYP58xWQwjZtVxcYFSxpSiruKo1qQnm7WyYcOG@mail.gmail.com>
Date: Thu, 31 Mar 2011 09:43:29 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: Tomas Hoger <thoger@...hat.com>
Cc: oss-security@...ts.openwall.com, Ludwig Nussel <ludwig.nussel@...e.de>, 
	Petr Baudis <pasky@...e.cz>
Subject: Re: Suid mount helpers fail to anticipate RLIMIT_FSIZE

>> Do you plan to open bug in glibc bugzilla for this issue?
>>
>
> Sure, I'll open one today.
>

"Today" ended up meaning "next week", but there's now a glibc bugzilla
entry for this:
http://sourceware.org/bugzilla/show_bug.cgi?id=12625

As indicated in my previous email, some of the helpers will need fixes
to completely resolve this issue.  In particular:

* util-linux mount should modify its custom addmntent function to
behave as suggested in the glibc bug report, and should improve its
error handling on addmntent failure to remove lockfiles and temporary
files.

* If mount.cifs is still shipped by anyone as setuid (I know there was
discussion of removing its suid bit), then it will need to be altered
to edit a temp file instead of /etc/mtab directly and clean up on
addmntent failure.

* If ncpfs is still supported by anyone (it's orphaned in a number of
distributions), it should be fixed to have ncpmount edit a temp file
instead of /etc/mtab directly and have both ncpmount and ncpumount
clean up properly on addmntent failure.


Alternatively, I'd be happy to see mount.cifs and the ncpfs utils no
longer ship with a suid bit, since they've had security issues in the
past and I don't think there's many situations where unprivileged
users need the ability to mount filesystems other than FUSE.  I'd also
like to see distributions migrating away from /etc/mtab in general,
since /proc/mounts seems like a much better replacement.

The above issues will probably need CVE identifiers of their own, but
I'd hold off on assigning them until it's clear that glibc is amicable
to the proposed solution.  Otherwise, there may need to be other fixes
involving raising resource limits (I hope not).

-Dan

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.