[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110725232208.GC23791@openwall.com>
Date: Tue, 26 Jul 2011 03:22:08 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Jan Lieskovsky <jlieskov@...hat.com>,
Panu Matilainen <pmatilai@...hat.com>,
Jindrich Novy <jnovy@...hat.com>, Florian Festi <ffesti@...hat.com>,
Matt McCutchen <matt@...tmccutchen.net>,
yersinia <yersinia.spiros@...il.com>, Jeff Johnson <n3npq@....com>
Subject: Re: CVE Request -- rpm -- Fails to remove the SUID/SGID bits on package upgrade (RH BZ#598775)
Vasiliy,
On Mon, Jul 25, 2011 at 09:30:35PM +0400, Vasiliy Kulikov wrote:
> On Mon, Jul 25, 2011 at 06:08 +0400, Solar Designer wrote:
> > case FSM_UNLINK:
> > - rc = Unlink(fsm->path);
> > + {
> > + struct stat stb;
> > + int saved_errno;
> > + int saved_rc = lstat(fsm->path, &stb);
> > + if (!saved_rc && !S_ISLNK(stb.st_mode))
> > + saved_rc = chmod(fsm->path, 0);
>
> If the directory containing the file was owned by nonroot, then the file
> could be overwritten with a symlink. So, there is a race between
> lstat() and chmod(), which might lead to chmod'ing arbitrary files by
> directory owner.
Right. The same risk is present in upstream's version of the fix.
> Is it possible with these orphaned files (I'm not familiar with the code
> in question)?
Yes, but this problem is not limited to this specific piece of code.
rpm appears to treat the target directory tree as trusted - not only
when it removes files, but also when it creates files, etc. I did not
fully verify this, though - that's just how the code looks to me.
This general issue is in fact a security risk. For example, if the
directory tree contains a subdirectory writable by a pseudo-user, then a
possible compromise of this pseudo-user account might lead to worse
things via rpm. Here's an example of such directory on Owl:
# ls -la /var/lib/dhcp/dhcpd/state/
total 8
drwxrwx--T 2 root dhcp 4096 Dec 14 2010 .
drwxr-x--- 3 root dhcp 4096 Dec 8 2010 ..
-rw------- 1 dhcp dhcp 0 Dec 8 2010 dhcpd.leases
We may discuss this general issue (of rpm trusting the target tree, and
the resulting risks) separately.
Thank you for the review!
BTW, another detail I thought someone might notice is that I am applying
the chmod's not only to binary packages, like the upstream fix does, but
I think also to source packages being removed/upgraded (I did not
actually test this, though). This might be excessive, or it might not,
but I felt that it does not hurt either way.
Alexander
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.
