Date: Tue, 29 Jan 2013 07:43:45 +0100 From: Willy Tarreau <w@....eu> To: oss-security@...ts.openwall.com Cc: Kurt Seifried <kseifried@...hat.com> Subject: Re: [Security hardening] [Notification] haproxy (previously) failed to drop supplementary groups after setuid / setgid calls properly Hi guys, On Thu, Jan 24, 2013 at 10:10:52PM -0500, Steve Grubb wrote: > On Thursday, January 24, 2013 05:53:38 PM Kurt Seifried wrote: > > So again, if you know of a way to exploit this please let us know, > > otherwise we will continue to consider this a security hardening issue > > and not a security vulnerability. > > The way these supplemental group issues work is that depending on the groups > file, the daemon may try to change to user/group "nobody", but retains group > root. This means that any file with group root write privs could be > replaced/altered. My experience is that distros have enough files that > permissions are wrong on something, somewhere. Its just a matter of finding it. > > find / -type f -perm -00020 -printf "%-60p %g\t%M\n" 2>/dev/null > > So, it boils down to the problem isn't a vulnerability by itself. However, > should a _real_ vulnerability be found in the program, the CVSS score would be > higher because the program has CWE-250. We had no problem having a CVE for this and I initially asked for one. However, no vulnerability can be described, precisely because haproxy is designed *not* to access the FS at all once started. The normal way of working is to start it as root, jail into a chroot and drop privileges, as it's just a network daemon. That's also why it logs over UDP, as it cannot access /dev/log. The user/group priv drop are just a hardening measure "just in case". Same for the chroot. Still, many people run it as root because they need transparent proxy support, and other ones don't chroot it because they start it as an application user. That does not make them vulnerable at all. So if normal use cases are not vulnerable, it seems reasonable to think that the slightly hardened ones are not much. But again, I'm not against a CVE, quite the opposite! Someone just has to describe how to abuse it for this I think. Regards, Willy
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.