Created attachment 677460 [details] patch to reset group membership While running various scripts made by Steve Grubb ( http://people.redhat.com/sgrubb/security/ ) on my Fedora system, I have found out that Haproxy do not call initgroups after setuid/setgid, and thus retain some of the privileges of the root user. Depending on the configuration of the system, this could lead to unintentional privileges escalation in case of another security vulnerability. For example, on a Fedora 18 system, using the default configuration for a haproxy ( ie, setuid and setgid to a user haproxy without privileges ), started by root, outside of systemd with : # haproxy -f /etc/haproxy/haproxy.cfg -d -V I can see on another console : # ps a -o pid,user,group,command | grep hapr 3545 haproxy haproxy haproxy -f /etc/haproxy/haproxy.cfg -d -V 4356 root root grep --color=auto hapr # grep Group /proc/3545/status Groups: 0 1 2 3 4 6 10 # getent group wheel wheel:x:10:root,misc # groups root bin daemon sys adm disk wheel So haproxy retained the wheel group membership, which was likely a unintended effect. ( and the others too ). Upstream main developper ( Willy Tarreau ) was notified by mail ( cc kurt ) already 5 minutes ago, with the patch attached to this bug report, against a fresh git clone of the repository. I asked him how he want to handle it with regards to a embargo, since the issue is not public yet. I will update this bug if he give me any feedback.
I also just checked that using haproxy with systemd totally mask the issue, since systemd clear the group membership before starting anything.
Finally, upstream wrote a 3rd patch, who should take care of a corner case ( ie someone using setgid when run as simple user, or something like that ) and is simpler than mine ( ie, directly drop all groups. I rediffed against latest git as he sent it to me by mail, so formatting or details may differ. Also, discussing wit Kurt by email, we were a little bit too optimistic to qualify that as a security vulnerability, while this is just a failure to harden the process. I do not know if that change much to the process on your side.
Regarding the patch, I'd consider calling exit(1) if setgroups failed. Not doing that leads to CWE-250: Execution with Unnecessary Privileges. Meaning that should another vulnerability be found that is exploitable and the app is running with too much privileges, the attacker could then start to write to files that are group writable and possibly become a persistent compromise.
Created attachment 678262 [details] 2nd proposal That's the 2nd proposal upstream suggested ( modulo formatting ). I think may we should invite him to discuss here instead of having me doing the middle man :) ( email w, not sure if he has a bugzilla account )
Created attachment 680418 [details] Propoxed upstream patch
Relevant upstream patch: [1] http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=ab012dd3
What happened with the upstream patch? I checked the upstream git repo and it appears the fix was only merged into development branch.
(In reply to comment #10) > What happened with the upstream patch? I checked the upstream git repo and > it appears the fix was only merged into development branch. Hi Ryan, do you need that patch backported against some concrete versions? If so, let me know and I will check with upstream to get it. Ad what happened with upstream patch - assuming since this wasn't considered as a security flaw, it hasn't been backported into older releases. Jan.
(In reply to comment #11) > (In reply to comment #10) > > What happened with the upstream patch? I checked the upstream git repo and > > it appears the fix was only merged into development branch. > > Hi Ryan, > > do you need that patch backported against some concrete versions? If so, > let me know and I will check with upstream to get it. Ad what happened with > upstream patch - assuming since this wasn't considered as a security flaw, > it hasn't been backported into older releases. > > Jan. Backporting this is simple. I was just under the assumption that this was fixed in the stable release. When possible, I prefer not to diverge from upstream.
I've talked with upstream developers and I expect this will be fixed in stable branch and released as 1.4.23. Stay tuned.
haproxy-1.4.23-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/haproxy-1.4.23-1.fc19
haproxy-1.4.23-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/haproxy-1.4.23-1.fc18
Package haproxy-1.4.23-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing haproxy-1.4.23-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4783/haproxy-1.4.23-1.fc19 then log in and leave karma (feedback).
haproxy-1.4.23-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/haproxy-1.4.23-2.fc19
haproxy-1.4.23-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
haproxy-1.4.23-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.