Red Hat Bugzilla – Bug 1000722
ngircd: failure to drop supplementary groups
Last modified: 2015-07-31 07:27:39 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 [127.0.0.1]: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.
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.
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.
Hi, Michael. Did upstream ever respond to this? I'm also fine with treating it as hardening rather than a security flaw.
upstream applied and released without CVE ( it was on 27/08 ). So i think this can be closed.
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: http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=e009ccbe66f67a4c5344d6a1f415c50b699765ad http://arthur.barton.de/cgi-bin/gitweb.cgi?p=ngircd.git;a=commitdiff;h=41f75b69740bd205864bd34afbb65ab0a3776136 (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.
Created ngircd tracking bugs for this issue: Affects: fedora-all [bug 1044619] Affects: epel-all [bug 1044620]