mailing list archives
Re: CVE Request -- rpm -- Fails to remove the SUID/SGID bits on package upgrade (RH BZ#598775)
From: Solar Designer <solar () openwall com>
Date: Tue, 26 Jul 2011 03:22:08 +0400
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:
- 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
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
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/
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.