Re: CVE Request: powerdns does not clear supplementary groups

[Steve Grubb <sgrubb () redhat com>]

On Thursday, May 24, 2012 04:57:30 PM Solar Designer wrote:
> Kurt -
>
> On Thu, May 24, 2012 at 02:33:06PM -0600, Kurt Seifried wrote:
> > [...] when a program
> > with much more limited operations doesn't drop privileges, unless it
> > directly leads to some sort of exploit/elevated access/etc. than I'm
> > inclined to say while it's not good, it's not a vulnerability per se.
>
> It's a case of a security feature not working as intended. 

I have to agree. Changing UID/GID from root to something else is a security 
feature by reducing privileges and write access to system files. Not doing it 
correctly is CWE-271. Looking it up, you can easily find 2 CVE's that are about 
not dropping supplemental groups.

If it were intended that you change uid/gid but retain a supplemental group, 
then you don't understand how /etc/group was supposed to be setup and used. 
Additionally you would have called initgroups() to pickup the new group 
memberships associated with that acct. So, its always wrong to call setgid()||
setuid() without taking care of supplemental groups.

Failing to drop supplemental groups, though, is not a vulnerability. Its an 
exposure to risk because you can bet someone will find another hole and exploit 
it and these extra privs allow them to escalate further.


> Previously,
> CVEs were sometimes assigned and sometimes not in such cases, and I
> failed to see a pattern in that. ;-)  Consider e.g. CVE-2006-5794 ("it
> is believed that this issue is only exploitable by leveraging
> vulnerabilities in the unprivileged process, which are not known to
> exist").  Are you maybe trying to draw the line between "security
> feature" and "security hardening"?  Even if so, I fail to see how
> OpenSSH's privsep is more of a "security feature", whereas another
> daemon's dropping of root privs is "security hardening".  These look
> very similar to me in terms of what they're intended and expected to
> achieve, so I think it's the same category, whatever we call it.
>
> Now, I imagine there could be a subtle case if e.g. a downstream distro
> or a fork of a project introduces privilege dropping, which is not in
> the main code base, and there turns out to be a flaw in that, which
> weakens the added security (but not to the point of being worse than the
> original).  It would feel a bit weird to say that the hardened revision
> is vulnerable whereas the original is not, even though the original is
> not any safer.  In such cases, I guess whether this is CVE-worthy or not
> will depend on whether the added hardening was advertised to and
> expected by users/admins of the hardened revision or not.  If it was an
> undocumented extra, then it failing to improve things is probably not
> what people would expect to be tracked as a security vulnerability.
> However, if it was documented and expected to function, then it becomes
> a vulnerability to track just like any other one of similar severity.


Here is a real life case:

+ if ( initgroups(pw->pw_name, NULL) != 0 || setgid(pw->pw_gid) != 0 ||
+                                setuid(pw->pw_uid) != 0 ) 

This is not upstream. This is a patch to drop capabilities by changing uid/gid. 
The person writing the patch intended to do the right thing - but failed. See 
the bug? This is in a network facing daemon that parses untrusted network 
packets.

-Steve