Re: CVE Request: powerdns does not clear supplementary groups

[Steve Grubb <sgrubb () redhat com>]

On Thursday, May 24, 2012 02:40:10 PM Kurt Seifried wrote:
> CC'ing the PowerDNS guys.
>
> On 05/24/2012 10:20 AM, David Black wrote:
> > Powerdns does not drop/clear supplementary groups in its dropPrivs
> > routine where the intent is to drop privileges.
> >
> > The relevant code can be found in pdns/unix_utility.cc /
> > pdns-recursor-3.3/unix_utility.cc [0].
> >
> > Can a CVE id be assigned for this issue?
> >
> >
> > [0] pdns/unix_utility.cc / pdns-recursor-3.3/unix_utility.cc //
> > Drops the program's privileges. void Utility::dropPrivs( int uid,
> > int gid ) { if(gid) { if(setgid(gid)<0) {
> > theL()<<Logger::Critical<<"Unable to set effective group id to
> > "<<gid<<": "<<stringerror()<<endl; exit(1); } else
> > theL()<<Logger::Info<<"Set effective group id to "<<gid<<endl;
> >
> > }
> >
> > if(uid) { if(setuid(uid)<0) { theL()<<Logger::Critical<<"Unable to
> > set effective user id to "<<uid<<":  "<<stringerror()<<endl;
> > exit(1); } else theL()<<Logger::Info<<"Set effective user id to
> > "<<uid<<endl; } }
>
> So the dropping of groups and the dropping of supplementary groups has
> come up a lot recently, here are my personal thoughts on the matter
> (with thanks to Steve Grubb for explaining some of the trickier bits).
> These are of course my personal opinions, any mistakes/errors are mine
> entirely and so on.
>
> Dropping of the primary user and group privileges is a well known
> security feature in many programs (e.g. bind, dhcp, apache, etc.). The
> idea being programs need root to bind to privileged ports/etc. But
> once done don't need root access. I think clearly in this case if a
> program is running as root, and claims to give up root privileges but
> fails to, that is a security issue and worthy of a CVE. In the case
> where a program does NOT drop privileges, and this feature has now
> been added (and assuming it works), I think this qualifies as security
> hardening, not a security fix and NOT worthy of a CVE.
>
> Now it gets messy. What about the dropping of supplementary groups?
>
> Supplemental groups enabled a user to be a member of more than one
> group at a time (us old timers remember the joys of "newgrp"). Why
> would anyone want this? You could for example create a group that has
> permissions to access logging, terminals (e.g. modems, remember those?
> =) and then add users to it as appropriate (and centralize
> account/permissions management somewhat and all that good stuff).
>
> So what happens when a program starts running as say root, and root
> has supplemental groups (like "bin" or "daemon" and the program drops
> its primary user/group but fails to drop supplementary groups, is that
> a security issue, and is it worthy of a CVE identifier?
>
> For most cases I'm going to say probably not (aka no). Having
> supplementary groups is intentional and allows permissions to be more
> fine grained, you can for example make root a member of "logging" so
> that even when the app drops root privileges would still have the 
> supplementary group of "logging" and can do its logging or whatever.

Supplemental groups are just for file access or anything that does a group 
permission check. The only way to determine if this is a security problem is to 
run the find command looking for any file with that group. Maybe something like 
this (assuming root):

find / -path /proc -prune -o -type f -gid 0 -perm /00030 -printf "%-55p %g\t%M\n" 

What programs that don't drop privs correctly does is call attention to it as 
something that should be attacked because it can be used as a stepping stone to 
other parts of the system. On the programming side, these should always be fixed 
so that we err on the side of caution. On the CVE issuing side you probably want 
to see what files exist with permissions that could be used to help decide its 
importance.

For example, there are a number of files that are group root writable and even 
more that are group root readable. So, dropping root badly can eventually lead 
to system compromise in a few steps. but when other groups are involved, you 
need to run the find command.

For anyone wanting to go bug hunting, I have a script here:
http://people.redhat.com/sgrubb/security/find-nodrop-groups
that can be used. It finds many, many problems dropping supplemental groups. More 
than I alone want to fix.

-Steve


> So unless someone makes a compelling argument that these are security
> issues I'm going to err on the side of "security hardening" instead of
> "security fix" for dropping supplementary groups, but of course not
> all issues are the same so if you have a specific issue and think it
> deserves a CVE make a case on OSS-sec.
>
> * Should these issues be fixed? yes. Dropping privileges where
> possible is usually a good idea, until things break though and then
> people start disabling things like SELinux or running everything as
> root to "make it work" :P.