Bug 1000722 - ngircd: failure to drop supplementary groups
ngircd: failure to drop supplementary groups
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 1044619 1044620
Blocks: 1001205
  Show dependency treegraph
Reported: 2013-08-24 12:51 EDT by Michael Scherer
Modified: 2015-07-31 07:27 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-18 12:16:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Scherer 2013-08-24 12:51:30 EDT
ngircd do not drop supplementary groups when run, which mean it is still running with partially elevated privileges.

Using the default config :

# ngircd -n
[12357:4    0] Can't read MOTD file "/etc/ngircd.motd": No such file or directory
[12357:4    0] No administrative information configured but required by RFC!
[12357:5    0] ngIRCd 20.2-IDENT+IPv6+IRCPLUS+SSL+SYSLOG+TCPWRAP+ZLIB-x86_64/redhat/linux-gnu started.
[12357:6    0] Using configuration file "/etc/ngircd.conf" ...
[12357:6    0] Running as user ngircd(468), group ngircd(452), with PID 12357.
[12357:6    0] Not running with changed root directory.
[12357:6    0] IO subsystem: epoll (hint size 100, initial maxfd 100, masterfd 3).
[12357:6    0] Now listening on []:6667 (socket 6).

On another terminal

$ grep Group /proc/12357/status
Groups:	0 1 2 3 4 6 10 

that's root, bin, daemon, sys, adm, disk and wheel. The last one is IMHO quite problematic.

Indeed, looking at the code, it fail to call initgrp to make sure the supplementary group are dropped. 

This is not a issue on systemd since it start with a empty environment, but is a issue on RHEL 6 ( likely for EPEL ).

I didn't notify upstream yet, nor asked for a CVE, and do not have a patch ready now, but I will be working on a patch if time permit. Following what was done on https://bugzilla.redhat.com/show_bug.cgi?id=894626 , I marked it as a security issue.
Comment 1 Vincent Danen 2013-08-26 13:21:12 EDT
Hi, Michael.  Please do let upstream know about this issue.  If they're unaware of it, I can certainly assign a CVE on their behalf.  I do see they just released 20.3 which fixed a DoS condition, so they should be quite responsive to this flaw as well.
Comment 2 Michael Scherer 2013-08-26 16:24:13 EDT
Will do.

Not sure if that deserve a CVE since there is no direct privileges escalation, and I found quite a lot of similar problem in Fedora ( using rpmlint and checking manually ). Last time I found one ( for haproxy ), we concluded this was just a failure to harden the system and didn't gave a CVE.
Comment 3 Vincent Danen 2013-11-28 11:50:19 EST
Hi, Michael.  Did upstream ever respond to this?

I'm also fine with treating it as hardening rather than a security flaw.
Comment 4 Michael Scherer 2013-11-28 17:41:22 EST
upstream applied and released without CVE ( it was on 27/08 ). So i think this can be closed.
Comment 5 Vincent Danen 2013-12-18 12:08:16 EST
Right, this was fixed in ngIRCd 21-rc1 as per http://ngircd.barton.de/doc/ChangeLog :

- Correctly discard supplementary groups on server startup.

Both Fedora 19 and 20 have this new version.

Upstream commits that may be suitable for EPEL:


(the first is the actual fix, the second is also required)

Even though we are treating this as hardening, I'm going to file a tracking bug for EPEL as I think it would be worthwhile to get in there.
Comment 6 Vincent Danen 2013-12-18 12:09:10 EST
Created ngircd tracking bugs for this issue:

Affects: fedora-all [bug 1044619]
Affects: epel-all [bug 1044620]

Note You need to log in before you can comment on or make changes to this bug.