Bug 894626 - haproxy: Fails to properly drop supplementary groups after setuid / setgid calls
Summary: haproxy: Fails to properly drop supplementary groups after setuid / setgid calls
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: haproxy
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ryan O'Hara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-12 18:37 UTC by Michael S.
Modified: 2013-04-27 03:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-26 23:59:29 UTC


Attachments (Terms of Use)
patch to reset group membership (2.22 KB, patch)
2013-01-12 18:37 UTC, Michael S.
no flags Details | Diff
2nd proposal (436 bytes, patch)
2013-01-14 15:32 UTC, Michael S.
no flags Details | Diff
Propoxed upstream patch (2.34 KB, patch)
2013-01-17 18:04 UTC, Jan Lieskovsky
no flags Details | Diff

Description Michael S. 2013-01-12 18:37:54 UTC
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.

Comment 1 Michael S. 2013-01-12 18:58:22 UTC
I also just checked that using haproxy with systemd totally mask the issue, since systemd clear the group membership before starting anything.

Comment 5 Michael S. 2013-01-14 15:05:39 UTC
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.

Comment 6 Steve Grubb 2013-01-14 15:12:03 UTC
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.

Comment 7 Michael S. 2013-01-14 15:32:19 UTC
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@1wt.eu, not sure if he has a bugzilla account  )

Comment 8 Jan Lieskovsky 2013-01-17 18:04:05 UTC
Created attachment 680418 [details]
Propoxed upstream patch

Comment 9 Jan Lieskovsky 2013-01-23 16:16:35 UTC
Relevant upstream patch:
[1] http://git.1wt.eu/web?p=haproxy.git;a=commitdiff;h=ab012dd3

Comment 10 Ryan O'Hara 2013-03-19 04:09:48 UTC
What happened with the upstream patch? I checked the upstream git repo and it appears the fix was only merged into development branch.

Comment 11 Jan Lieskovsky 2013-03-19 08:49:29 UTC
(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.

Comment 12 Ryan O'Hara 2013-03-19 14:34:38 UTC
(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.

Comment 13 Ryan O'Hara 2013-03-19 15:51:32 UTC
I've talked with upstream developers and I expect this will be fixed in stable branch and released as 1.4.23. Stay tuned.

Comment 14 Fedora Update System 2013-04-03 05:02:59 UTC
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

Comment 15 Fedora Update System 2013-04-03 05:05:51 UTC
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

Comment 16 Fedora Update System 2013-04-03 16:15:17 UTC
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).

Comment 17 Fedora Update System 2013-04-22 15:23:33 UTC
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

Comment 18 Fedora Update System 2013-04-26 23:59:32 UTC
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.

Comment 19 Fedora Update System 2013-04-27 03:05:44 UTC
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.


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