[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110427201047.08f42008@orphan>
Date: Wed, 27 Apr 2011 20:10:47 +0200
From: Tomas Hoger <thoger@...hat.com>
To: dan.j.rosenberg@...il.com, "Steven M. Christey" <coley@...us.mitre.org>
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
On Wed, 27 Apr 2011 11:00:16 -0400 Dan Rosenberg wrote:
> >> 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)
> >
> > Dan, would you mind clarifying the way to achieve mtab corruption
> > via truncated left-over mtab.tmp file and multiple invocations?
> > After some discussion with our util-linux maintainer, we fail to
> > see an obvious way. util-linux opens mtab.tmp using "w" fopen
> > open, i.e. using O_TRUNC open flag. So if there's any mtab.tmp
> > file found, it's overwritten and its existence does not block
> > further use of mount / umount as existence of mtab~ lock file does.
>
> Ah, quite right. I missed that since I was just doing a quick survey
> of a bunch of helpers. It seems the mtab.tmp file isn't an issue.
> Thanks for looking into it.
Ok, thank you!
Steve, it seems CVE-2011-1676 should get marked as rejected or disputed.
Thanks!
--
Tomas Hoger / Red Hat Security Response Team
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.
