Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 06 Jun 2012 23:03:16 -0600
From: Kurt Seifried <>
To: "" <>
Subject: Some notes on CVE's and group privilege dropping

Hash: SHA1

So there are a lot of group privilege related issues in Linux and UNIX
programs due to the simple fact a lot of stuff needs limited elevated
privileges for something like binding to a privileged port or
accessing a file with restricted permissions. The usual solution is to
start running as root (using setuid or setgid), execute the code
requiring privilege and then drop privileges to an account such as
"apache", "bind" or the user running the program. Many programs fail
to properly drop privileges, in some cases they even manage to add
additional privileges in an attempt to drop them leading to security
risks and trust boundary violations. On the other hand some privilege
dropping problems are quite benign and can be classified as security

So with this in mind when is a group dropping issue severe enough to
be considered a security fix as opposed to security hardening, and for
what should a CVE be assigned (please note that this is not set in
stone, make a good case for something and it can potentially get a CVE).

1) Is there a trust boundary violated, or an exploit for this to gain
privilege, gain access, cause a significant DoS, etc.? Examples would
be arpwatch adding root privileges. Especially if you can show exploit
code for this then it's pretty obviously a security issue.

As reported on the oss-security mailing list [1] the
arpwatch-drop.patch as included in Red Hat arpwatch packages does not
properly drop capabilities when changing uid/gid. It calls
initgroups() as:

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

However in this case, the NULL results in group 0 being added to the
supplementary groups list.

2) Is the program documented as dropping privileges, do people expect
it to drop privileges and be relying on this as a secure feature? If
so it would earn a CVE (security features that fail to work typically
get a CVE).

3) Does the program attempt to drop privileges in code? This is where
things become a grey area, if it is not documented as such (in
documents, source code, etc.) and people generally don't rely on it to
drop privileges I'm less inclined to assign a CVE and class this
instead as a security hardening issue. Unless it falls into the first
category of having an exploit or something clever that can be
triggered, then make a case.

4) The program makes no attempt at all to drop privileges, typically
no CVE issued as this is security hardening. Unless it falls into the
first category of having an exploit or something clever that can be
triggered, then make a case.

More info: Steve Grubb has made some excellent postings on this:

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


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.