This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 847402 (CVE-2012-3524)

Summary: CVE-2012-3524 dbus: privilege escalation when libdbus is used in setuid/setgid application
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: ajax, bugzilla, cfergeau, colin, ddumas, hdegoede, jlieskov, law, mclasen, rcvalle, security-response-team, walters
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=important,public=20120912,reported=20120727,source=oss-security,cvss2=6.9/AV:L/AC:M/Au:N/C:C/I:C/A:C,rhel-5/dbus=notaffected,rhel-6/dbus=affected,fedora-all/dbus=affected,cwe=CWE-426
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-08 13:47:22 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 854820, 854821, 857226    
Bug Blocks: 847403    
Attachments:
Description Flags
glib2: use __secure_getenv, don't run dbus-launch as root
none
dbus: Use __secure_getenv
none
updated glib patch
none
updated dbus patch
none
updated glib patch none

Description Vincent Danen 2012-08-10 17:26:04 EDT
X.org has traditionally been suid root so that users could utilize "startx" (or similar scripts) to start X from the command line as a user.  X.org does not sanitize the environment when starting, which means it will be aware of, and pass along, environment variables.  When X.org is using the DBus backend, specifically versions 1.5.x or newer, the DBUS_SYSTEM_BUS_ADDRESS environment variable is passed along to libdbus.  The DBUS system address can take a unixexec (Executed Subprocess on UNIX) transport [1] which allows one to specify a binary to execute and arguments to pass to it.

Because the DBUS_SYSTEM_BUS_ADDRESS environment variable is not scrubbed by X, this environment variable is passed along to libdbus, and it specifies the address of the system message bus.  A malicious local user could use this, in conjunction with the unixexec transport, to execute arbitrary code as root (because /usr/bin/Xorg is suid root).

[1] http://dbus.freedesktop.org/doc/dbus-specification.html#transports-exec

Acknowledgements:

Red Hat would like to thank Sebastian Krahmer of the SUSE Security Team for reporting this issue.
Comment 1 Colin Walters 2012-08-10 20:03:40 EDT
(In reply to comment #0)
> X.org has traditionally been suid root so that users could utilize "startx"
> (or similar scripts) to start X from the command line as a user.  X.org does
> not sanitize the environment when starting,

This is slightly inaccurate - it *does* sanitize a few environment variables.  Just not ones that are problematic.

http://cgit.freedesktop.org/xorg/xserver/tree/os/utils.c?id=7f09126e068015db54c56bb982b8f91065375700#n1744
Comment 2 Vincent Danen 2012-08-13 16:27:47 EDT
Ahh, thanks for the clarification.  Should be rather that Xorg sanitizes a very small number of environment variables, such as LD_*.
Comment 4 Colin Walters 2012-08-21 11:03:22 EDT
Ok, unfortunately it turns out there is another setuid binary included in Fedora at least that links to libdbus, and doesn't clear its environment:

/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper

Part of the spice-glib package.  Shipped in RHEL6 even.  

This was reported by Sebastian Krahmer <krahmer@suse.de>; he wrote a working exploit for Fedora 17.  It is likely possible to make it work on RHEL6 as well.

We should clone this bug, and get the spice-glib package fixed to harden its environment at a minimum.  Even better, to not link against libdbus or libgio for that matter.

Upstream for libdbus we're reconsidering our position on automatically using glibc __secure_getenv().  So it may make sense to issue a dbus update too.
Comment 8 Colin Walters 2012-08-21 17:06:06 EDT
Created attachment 606063 [details]
glib2: use __secure_getenv, don't run dbus-launch as root
Comment 9 Colin Walters 2012-08-21 17:08:40 EDT
Created attachment 606064 [details]
dbus: Use __secure_getenv

This patch is from Sebastian Krahmer <krahmer@suse.de>, commit message written by me.
Comment 13 Colin Walters 2012-08-21 20:25:19 EDT
So it turns out it's a lot less lame to use glibc's __libc_enable_secure, except it was never actually exported officially.  It has always apparently worked to link to it and use it, but the RPM dependency generator (correctly) blows up now when used with new binutils.

http://www.openwall.com/lists/owl-dev/2012/08/14/1

Jeff, can we get that patch upstream?
Comment 14 Colin Walters 2012-08-21 20:26:09 EDT
See also: http://osdir.com/ml/linux.lfs.hardened/2007-04/msg00031.html
Comment 16 Colin Walters 2012-08-21 20:49:18 EDT
Created attachment 606084 [details]
updated glib patch
Comment 17 Kurt Seifried 2012-08-22 02:30:18 EDT
So we have a complicated CVE assignment. Basically we have three sets of issues:

1) setuid apps like startx
2) glibc getenv() / __secure_getenv() / secure_getenv()
3) libdbus versions 1.5.x or newer, the DBUS_SYSTEM_BUS_ADDRESS environment variable is supported

Now taken individually none of these really represent a security boundary violation. Setuid applications are in and of themselves not a security issue. Unless an application was accidentally made setuid (e.g. an error in an RPM spec file or something) being setuid is not a CVE worthy issue. The Glibc getenv is again not in and of itself an issue typically, moving to secure_gentenv is generally a security hardening issue. Finally we have libdbus, which now supports DBUS_SYSTEM_BUS_ADDRESS, which takes an executable as an argument. Again this is documented and intended behaviour.

So what are we to do? There is obviously a security issue present. Obviously giving a local user the ability to gain root access is not the intent of X.org/libdbus/etc. 

Although the CVE dictionary typically specifies a CVE entry for a single security issue (or set of related issues) it does allow for the combination of multiple issues that individually are not serious, but in conjunction with each other can be used to violate a security boundary[CVE conjunction]. 

So in conjunction these issues definitely deserve a CVE. Please use CVE-2012-3524 for this issue. Specifically in CVE description style:

Local root code execution is possible when a setuid/setgid application (such as start from X.org) using libdbus fails to properly sanitize environmental variables due to use of glibc getenv (instead of secure_getenv). This allows users to pass the DBUS_SYSTEM_BUS_ADDRESS environmental variable to libdbus which takes an executable as an argument which is then run as the setuid/setgid user (such as root). 

And yes any program using glibc getenv (especially those using libdbus) should be fixed to use secure_getenv.

[CVE conjunction]
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=conjunction
Comment 20 Colin Walters 2012-08-22 13:45:59 EDT
Created attachment 606355 [details]
updated dbus patch

This patch is modeled after the GLib one - rather than using __secure_getenv, we need to also ensure we don't run any binaries as root.
Comment 22 Colin Walters 2012-08-22 17:55:16 EDT
Created attachment 606392 [details]
updated glib patch

This one goes back to manually filtering environment variables - turns out the other approach may break "pkexec".
Comment 28 Tomas Hoger 2012-08-23 04:07:58 EDT
(In reply to comment #20)
> Created attachment 606355 [details]
> updated dbus patch

Ok, so is the plan to keep the hole open for any privileged program that gains privileges via file system capabilities?

> This patch is modeled after the GLib one - rather than using
> __secure_getenv, we need to also ensure we don't run any binaries as root.

For anything changed to use __secure_getenv, please check:
  http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv

as __secure_getenv should not longer be usable for use in new programs in future glibc versions.  secure_getenv should be used there instead.
Comment 29 Colin Walters 2012-08-23 09:32:24 EDT
(In reply to comment #28)
> (In reply to comment #20)
> > Created attachment 606355 [details]
> > updated dbus patch
> 
> Ok, so is the plan to keep the hole open for any privileged program that
> gains privileges via file system capabilities?

At the moment unfortunately yes; but I'm not aware of any fscaps binary that uses GLib.

Note that AT_SECURE is *also* set on SELinux domain transitions.  If more of userspace beyond glibc starts reacting to it, we could see more complex and subtle ramifications.  Probably mostly good - but for example, if there were a program linking to GLib today that was relying on propagating GIO_EXTRA_MODULES today to a child process or something, and there was a SELinux domain transition between them, it would stop working.

Admittedly very theoretical - but if you'd asked me earlier, I would have said polkit was the only setuid program linking to GLib...

> For anything changed to use __secure_getenv, please check:
>   http://sourceware.org/glibc/wiki/Tips_and_Tricks/secure_getenv

Ah.  Well, we're not relying on __secure_getenv anymore.

What I *do* want is either:
1) __libc_enable_secure exported
2) glibc to implement issetugid() like BSD has

Apparently *very* recent glibc versions have getauxval(), so other libraries could check AT_SECURE directly, but I'd still rather have issetugid().
Comment 39 Jeff Law 2012-09-06 00:40:46 EDT
BTW, I'm not 100% sure why I'm cc'd on this bug.    I'm responsible for glibc, not glib, they are totally unrelated.
Comment 40 Huzaifa S. Sidhpurwala 2012-09-06 00:58:56 EDT
(In reply to comment #39)
> BTW, I'm not 100% sure why I'm cc'd on this bug.    I'm responsible for
> glibc, not glib, they are totally unrelated.

I think that was because of comment #13
Comment 50 Tomas Hoger 2012-09-07 10:00:41 EDT
(In reply to comment #17)
> So in conjunction these issues definitely deserve a CVE. Please use
> CVE-2012-3524 for this issue. Specifically in CVE description style:
> 
> Local root code execution is possible when a setuid/setgid application (such
> as start from X.org) using libdbus fails to properly sanitize environmental
> variables due to use of glibc getenv (instead of secure_getenv). This allows
> users to pass the DBUS_SYSTEM_BUS_ADDRESS environmental variable to libdbus
> which takes an executable as an argument which is then run as the
> setuid/setgid user (such as root).

Somewhat rewording this:

Local privilege escalation is possible when a setuid or setgid application (such as X.org X server) using libdbus 1.5.x or newer, if the application does not sanitize its environment. This allows unprivileged users to set the DBUS_SYSTEM_BUS_ADDRESS environmental variable read by libdbus which can contain a command that is executed by libdbus with the application privileges.

I'd say wording it as this really implies this is a CVE for dbus.  I'm not sure if such CVE can be used for applications updates, that add proper environment filtering and hence do not only plug attack vectors via libdbus, but also similar possible (but currently unknown) problems in other libraries.

I also think that we can't use this CVE for glib fix attached here, as that fix is to make sure glib is not found to be another libdbus, offering some way to escalate privileges if used by a privileged application.  I believe we will need at least one more CVE for glib for the "privileged app used in conjunction with glib".

I think it makes sense to consider separate CVE for applications that were running privileged and were not cleaning their environments before using non-trivial libraries, in addition to this libdbus should not [*] use environment settings when running privileged CVE.  It seems less confusing.

[*] with understanding that the "should not" part can be disputed.
Comment 51 Jeff Law 2012-09-07 13:38:40 EDT
Ah OK.  So you just want libc_enable_secure as part of the exported ABI/API from glibc.  If so that absolutely must happen upstream; exporting additional symbols in Fedora and/or RHEL isn't possible. 

Is that all that's needed?

jeff
Comment 54 Colin Walters 2012-09-10 09:46:18 EDT
(In reply to comment #51)
> Ah OK.  So you just want libc_enable_secure as part of the exported ABI/API
> from glibc.  If so that absolutely must happen upstream; exporting
> additional symbols in Fedora and/or RHEL isn't possible. 
> 
> Is that all that's needed?

Hi Jeff,

From glibc - yes.  Though it'd be great if you guys considered implementing issetugid() from BSD too.
Comment 55 Colin Walters 2012-09-10 10:34:49 EDT
(In reply to comment #50)
>
> I also think that we can't use this CVE for glib fix attached here, as that
> fix is to make sure glib is not found to be another libdbus, offering some
> way to escalate privileges if used by a privileged application. 

There are two known "vulnerability pairs":

RHEL6: libdbus + Xorg
RHEL7/F17: glib + spice-gtk

No objections to using separate CVEs for the pairs or for each one individually. 

But glib *is* part of a vulnerability pair.

> I believe
> we will need at least one more CVE for glib for the "privileged app used in
> conjunction with glib".

Right.

> I think it makes sense to consider separate CVE for applications that were
> running privileged and were not cleaning their environments before using
> non-trivial libraries, in addition to this libdbus should not [*] use
> environment settings when running privileged CVE.  It seems less confusing.

That seems reasonable to me.
Comment 58 errata-xmlrpc 2012-09-13 12:52:18 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2012:1261 https://rhn.redhat.com/errata/RHSA-2012-1261.html
Comment 63 Vincent Danen 2012-09-13 16:17:02 EDT
Created dbus tracking bugs for this issue

Affects: fedora-all [bug 857226]
Comment 65 Colin Walters 2012-09-13 18:47:10 EDT
Adam, Hans, are you guys on the ball for doing updates on your side?  Please?
Comment 66 Christophe Fergeau 2012-09-14 05:23:11 EDT
(In reply to comment #65)
> Adam, Hans, are you guys on the ball for doing updates on your side?  Please?

Looking at the spice-gtk side of things (upstream + fedora)
Comment 72 Geoffrey Thomas 2012-09-28 17:25:03 EDT
For the record, I'd like to note that there's a minor regression in this patchset, since dbus-daemon-launch-helper is a setuid binary that links libdbus, and does its own environment sanitization. Specifically, it attempts to pass through DBUS_STARTER_ADDRESS, but that now fails, meaning a d-d-l-h-activated program won't be able to find the system bus by asking for its starter bus. (I believe there's no commonly-used software that depends on this, but it's still documented as possible and d-d-l-h clearly attempts to make it work, and my company has internal software that depended on this functionality.)

Colin Walters and I put together a patch that works around this:
http://cgit.freedesktop.org/dbus/dbus/commit/?id=f68dbdc3e6f895012ce33939fb524accf31bcca5
It depends on a predecessor commit that just removes the DBUS_VERBOSE logic in the activation helper, since it's not useful.

This is in the D-Bus 1.6.8 release. I think he's decided that the regression isn't egregious enough to be worth backporting, but I figured I'd mention it in this bug anyway for future reference.
Comment 73 Tomas Hoger 2012-10-07 14:00:50 EDT
(In reply to comment #0)
> X.org has traditionally been suid root so that users could utilize "startx"
> (or similar scripts) to start X from the command line as a user.  X.org does
> not sanitize the environment when starting, which means it will be aware of,
> and pass along, environment variables.  When X.org is using the DBus
> backend, specifically versions 1.5.x or newer, the DBUS_SYSTEM_BUS_ADDRESS
> environment variable is passed along to libdbus.  The DBUS system address
> can take a unixexec (Executed Subprocess on UNIX) transport [1] which allows
> one to specify a binary to execute and arguments to pass to it.

Note that this issue was not limited to dbus versions 1.5 and later.  Initial reporter's public exploit uses "autolaunch:" bus address to achieve privilege escalation using a crafted dbus-launch program.