[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130129064345.GA12698@1wt.eu>
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.
