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.
(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
Ahh, thanks for the clarification. Should be rather that Xorg sanitizes a very small number of environment variables, such as LD_*.
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>; 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.
Created attachment 606063 [details] glib2: use __secure_getenv, don't run dbus-launch as root
Created attachment 606064 [details] dbus: Use __secure_getenv This patch is from Sebastian Krahmer <krahmer>, commit message written by me.
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?
See also: http://osdir.com/ml/linux.lfs.hardened/2007-04/msg00031.html
Created attachment 606084 [details] updated glib patch
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
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.
Created attachment 606392 [details] updated glib patch This one goes back to manually filtering environment variables - turns out the other approach may break "pkexec".
(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.
(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().
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.
(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
(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.
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
(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.
(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.
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
Created dbus tracking bugs for this issue Affects: fedora-all [bug 857226]
Adam, Hans, are you guys on the ball for doing updates on your side? Please?
(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)
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.
(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.