Bug 7474 - dbus new security issue CVE-2012-3524
: dbus new security issue CVE-2012-3524
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: All Linux
: Normal Severity: major
: ---
Assigned To: QA Team
:
: http://lwn.net/Vulnerabilities/516077/
: MGA1TOO mga2-64-OK MGA1-32-OK MGA1-64...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2012-09-13 21:43 CEST by David Walser
Modified: 2012-10-06 15:40 CEST (History)
10 users (show)

See Also:
Source RPM: dbus
CVE:
Status comment:


Attachments
0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch (6.43 KB, patch)
2012-09-13 21:45 CEST, David Walser
Details | Diff

Description David Walser 2012-09-13 21:43:40 CEST
RedHat has issued an advisory today (September 13):
https://rhn.redhat.com/errata/RHSA-2012-1261.html

SuSE has issued an advisory on September 12:
http://lists.opensuse.org/opensuse-security-announce/2012-09/msg00009.html

This is a rather confusing one, and discussions about it point to issues in Xorg, glib, glibc, dbus, and some other things, but the advisories that have come out have patched dbus, although it sounds like that doesn't solve all of the problems related to this.  It seems to have something to do with SUID executables and not sanitizing environment variables.  It sounds like all versions of dbus are impacted, and unknown versions of whatever else is impacted.

It looks like SuSE used this patch:
https://bugzilla.novell.com/attachment.cgi?id=498135

for their update; this was taken from their bug:
https://bugzilla.novell.com/show_bug.cgi?id=697105

it's also present on the OBS:
https://build.opensuse.org/package/view_file?file=dbus-cve-2012-3524.patch&package=dbus-1&project=home%3Amlin7442%3Abranches%3ABase%3ASystem&rev=1cb07bd21c7df9207ef326d7e91c345c

RedHat used a different and more complicated patch, which I'll attach shortly.

Both patches are against dbus 1.2.x.  SuSE's patch should still apply to 1.4.x that we have.  RedHat's patch does not.
Comment 1 David Walser 2012-09-13 21:45:32 CEST
Created attachment 2794 [details]
0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch

RedHat's patch.
Comment 2 David Walser 2012-09-13 21:48:07 CEST
I've CC'd everyone because of all of the packages potentially implicated by the issue, and because this is a core component (with no maintainer).
Comment 3 David Walser 2012-09-13 21:51:54 CEST
Here's the RedHat bug, with plenty more discussion on this:
https://bugzilla.redhat.com/show_bug.cgi?id=847402
Comment 4 David Walser 2012-09-13 21:54:32 CEST
The RedHat bug has a variant of their patch attached to it, looks like for a slightly different dbus version, and it also has a patch for glib.
Comment 5 Colin Guthrie 2012-09-14 09:42:41 CEST
If no one beats me (please do, as I'm totally swamped with work just now), I'll try and take a look on Saturday.
Comment 6 Colin Guthrie 2012-09-15 14:04:25 CEST
OK, submitted rebuild with the patch from Fedora.

mga2: dbus-1.4.16-5.2.mga2
mga1: dbus-1.4.1-3.1.mga1

Note that as we're using dbus 1.4.x the primary exploit vector is likely not present, so regression testing should likely be restricted to ensuring nothing breaks, especially when using in conjunction to setuid binaries linking to dbus.

I've also updated glib2.0 on mga2. The patch does not apply on mga1's glib package. It will take some effort to port the patch to an older version (probably not too crazy).

mga2: glib2.0-2.32.4-1.1.mga2
Comment 7 David Walser 2012-09-17 02:00:21 CEST
Everything submitted so far has been built.  glib2.0 for Mageia 1 pending.

dbus (Mageia 1):
dbus-1.4.1-3.1.mga1
libdbus-1_3-1.4.1-3.1.mga1
libdbus-1-devel-1.4.1-3.1.mga1
dbus-x11-1.4.1-3.1.mga1
dbus-doc-1.4.1-3.1.mga1

from dbus-1.4.1-3.1.mga1.src.rpm

dbus (Mageia 2):
dbus-1.4.16-5.1.mga2
libdbus-1_3-1.4.16-5.1.mga2
libdbus-1-devel-1.4.16-5.1.mga2
dbus-x11-1.4.16-5.1.mga2
dbus-doc-1.4.16-5.1.mga2

from dbus-1.4.16-5.1.mga2.src.rpm

glib2.0 (Mageia 2):
glib2.0-common-2.32.4-1.1.mga2
libglib2.0_0-2.32.4-1.1.mga2
libgio2.0_0-2.32.4-1.1.mga2
libglib2.0-devel-2.32.4-1.1.mga2
libglib2.0-static-devel-2.32.4-1.1.mga2
glib-gettextize-2.32.4-1.1.mga2

from glib2.0-2.32.4-1.1.mga2.src.rpm
Comment 8 Thomas Backlund 2012-09-17 10:24:37 CEST
(In reply to comment #7)
> Everything submitted so far has been built.  glib2.0 for Mageia 1 pending.
> 
> 
> glib2.0 (Mageia 2):
> glib2.0-common-2.32.4-1.1.mga2
> libglib2.0_0-2.32.4-1.1.mga2
> libgio2.0_0-2.32.4-1.1.mga2
> libglib2.0-devel-2.32.4-1.1.mga2
> libglib2.0-static-devel-2.32.4-1.1.mga2
> glib-gettextize-2.32.4-1.1.mga2
> 
> from glib2.0-2.32.4-1.1.mga2.src.rpm

This glib2.0 one can't be pushed as part of this update AFAIK as the version upgrade is part of the big GNOME update.... 

Olav can probably confirm it (or not)...
Comment 9 Colin Guthrie 2012-09-17 11:01:28 CEST
Ahhh right, good catch. I can create a branch for it, and patch the 2.32.1 version if needed, but it's probably not worth it.

To be honest, AFAICT, this is all a rather theoretical precationary effort when used with libdbus < 1.5 (which covers both mga2 and mga1) as they don't listen to the relevant env var that would cause problems - of course there could be other env vars used in various libraries that could cause problems to the whitelist approach suggested in these discussions makes sense generally.

Under mga1, I'm not sure we have any setuid glib apps (mga2 as the acl helper from spice-gtk package, but we don't have that on mga1 AFAICT).
Comment 10 David Walser 2012-09-17 15:32:33 CEST
OK, I guess we'll need glib2.0 deleted from updates_testing and resubmitted with a patch against the previous version, then the updated one can be resubmitted after this update is pushed.  Not updating glib2.0 in Mageia 1 sounds fine to me if we don't have spice-gtk.  RedHat and SuSE did update dbus even though they only had version 1.2.x, so I assume there must be a reason :o)
Comment 11 David Walser 2012-09-18 22:22:02 CEST
Fedora hasn't issued the update for glib2.0 yet, but it's in testing.  I think a notice will be put here when it's released:
https://bugzilla.redhat.com/show_bug.cgi?id=857227

As for spice-gtk, RedHat has issued an advisory on September 17:
https://rhn.redhat.com/errata/RHSA-2012-1284.html

CVE-2012-4425 has been assigned for the vulnerability of it with glib2.
Comment 12 David Walser 2012-09-20 19:55:58 CEST
I've created Bug 7536 for the spice-gtk/glib2.0 issue.

For dbus, this can be pushed to QA.

Advisory:
========================

Updated dbus packages fix security vulnerability:

It was discovered that the D-Bus library honored environment settings even
when running with elevated privileges. A local attacker could possibly use
this flaw to escalate their privileges, by setting specific environment
variables before running a setuid or setgid application linked against the
D-Bus library (libdbus) (CVE-2012-3524).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3524
https://rhn.redhat.com/errata/RHSA-2012-1261.html
========================

Updated packages in core/updates_testing:
========================
dbus-1.4.1-3.1.mga1
libdbus-1_3-1.4.1-3.1.mga1
libdbus-1-devel-1.4.1-3.1.mga1
dbus-x11-1.4.1-3.1.mga1
dbus-doc-1.4.1-3.1.mga1
dbus-1.4.16-5.1.mga2
libdbus-1_3-1.4.16-5.1.mga2
libdbus-1-devel-1.4.16-5.1.mga2
dbus-x11-1.4.16-5.1.mga2
dbus-doc-1.4.16-5.1.mga2

from SRPMS:
dbus-1.4.1-3.1.mga1.src.rpm
dbus-1.4.16-5.1.mga2.src.rpm
Comment 13 David Walser 2012-09-20 19:56:18 CEST
Colin, has this been fixed in Cauldron?
Comment 14 claire robinson 2012-09-21 16:24:32 CEST
PoC: http://www.exploit-db.com/exploits/21323/
Comment 15 claire robinson 2012-09-21 16:50:00 CEST
Testing mga2 x86_64

# urpmi spice-gtk

Edit 21323.c (The PoC) and change the path for the spice vector..

from:

char *spice[] = {"/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper", NULL};

to:

char *spice[] = {"/usr/bin/spice-client-glib-usb-acl-helper", NULL}; 

Then:

$ gcc 21323.c


Before
------
$ ./a.out
[**] CVE-2012-3524 xSports -- this is not a dbus exploit!

[*] Preparing ...
[+] Using spice helper ...
[*] Waiting 10s for dbus-launch to drop boomshell.
..........
[!] Hurra!

bash-4.2# touch /root/test.txt
bash-4.2# ls -l /root/test.txt
-rw-r--r-- 1 root root 31 Sep 21 15:38 /root/test.txt
bash-4.2# exit
exit
$

After
-----
Rebooting for dbus update then I'll try again..
Comment 16 claire robinson 2012-09-21 17:29:18 CEST
Hmm

After is just the same. I think this may be using the same CVE on spice-gtk with the modifications instead of dbus :\

It didn't previously work without spice-gtk so perhaps we are not vulnerable.

# urpme  spice-gtk

$ rm -f a.out
$ gcc 21323.c
$ ./a.out
[**] CVE-2012-3524 xSports -- this is not a dbus exploit!

[*] Preparing ...
[+] Using pam_systemd helper (type user passwd when asked) ...
[*] Waiting 10s for dbus-launch to drop boomshell.
Password: ......
bash: blah: No such file or directory
....^C

I stopped it in the end as that is where it got stuck. The No such file error occurs when entering the user password. I don't know C well enough to work out why. This result was the same before and after the update.

I tried removing "blah, NULL from the char su line but then it say this instead..
bash: PATH=/tmp:/usr/bin:/usr/sbin:/sbin:/bin: No such file or directory

My C Fu is not strong enough. Any clues?
Comment 17 claire robinson 2012-09-21 18:43:41 CEST
Aside from the PoC not working dbus seems to work as normal, watching syslog.

With spice-gtk installed however the PoC works before _and_ after installing the updates. I'm not sure whether that means I am testing spice-gtk instead of dbus though so will wait for some feedback please.
Comment 18 David Walser 2012-09-21 21:54:55 CEST
This bug is not regarding spice-gtk, where the vulnerability is in combination with glib2.0 (not dbus).  In fact, we need to update spice-gtk, but as far as I know nobody has built an update for that yet, and when we do it will be in Bug 7536.

This bug is regarding dbus in combination with X.org.

Looking at the exploit code, it looks like it's meant to exploit either of the two (related) vulnerabilities, but it tries the spice-gtk one first, which is why it is succeeding (you can see it say using spice helper).

You want it to say "using Xorg helper" and go from there.  I actually don't know what the pam_systemd helper is (is there yet another vulnerability?).

You might need to remove this section of code to get it to use the Xorg helper on Mageia 2:
else if (stat("/lib64/security/pam_systemd.so", &st) == 0) {
        printf("[+] Using pam_systemd helper (type user passwd when asked) ...\n");
        env[3] = "DISPLAY=:7350";
        su[1] = getenv("USER");
        a = su;
    }

If the pam_systemd helper does work, however, while that has nothing to do with this dbus update, it is something we'd need to be concerned about.  I saw you mention on IRC that it errored out about the blah, so it may be that you need to replace blah with a real command name.
Comment 19 David Walser 2012-09-21 21:55:40 CEST
Oh, I forgot to say (in case it's not obvious), uninstall spice-gtk to get it to skip the spice helper.
Comment 20 David Walser 2012-09-22 03:15:14 CEST
Samuel, I'd like to get confirmation from Colin that Cauldron is not affected before changing the version.
Comment 21 David Walser 2012-09-22 16:43:17 CEST
As Marc pointed out to me on IRC, the exploit program will still not use the Xorg helper on Mageia systems normally.  The reason for this is that /usr/bin/Xorg does not have the SUID bit.  I guess some other distros install that executable SUID root and we don't, so we are probably not vulnerable to the X.org problem specifically.  You can do (as root) this just for testing purposes to make it use the Xorg helper:
chmod u+s /usr/bin/Xorg

but make sure to reverse that when you're done testing:
chmod u-s /usr/bin/Xorg

Note that for the spice helper, this executable also needs the SUID bit:
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper

But given Claire's test, I guess it normally does.

Finally, when testing this on i586, you probably need to modify that path in the code, as well as this one:
/lib64/security/pam_systemd.so

to the appropriate equivalents.
Comment 22 Dave Hodgins 2012-09-22 21:20:47 CEST
On Mageia 1 ...

[root@x2v ~]# urpmq -i dbus --media "Core Updates"|grep -e Version -e Release
Version     : 1.4.1
Release     : 3.1.mga1
[root@x2v ~]# urpmq -i dbus --media "Core Updates Testing"|grep -e Version -e Release
Version     : 1.4.1
Release     : 3.1.mga1

Need to bump the sub release?
Comment 23 David Walser 2012-09-26 20:11:30 CEST
Fedora's advisories for these issues have now been released.

dbus:
http://lists.fedoraproject.org/pipermail/package-announce/2012-September/088256.html

glib2.0:
http://lists.fedoraproject.org/pipermail/package-announce/2012-September/088257.html

spice-gtk:
http://lists.fedoraproject.org/pipermail/package-announce/2012-September/088245.html

The glib2.0 advisory is using the same CVE as dbus, CVE-2012-3524.
Comment 24 Colin Guthrie 2012-09-27 00:42:55 CEST
Regarding the /usr/bin/Xorg and setuid, I suspect on Mageia that we need to worry about /usr/bin/Xwrapper which is setuid (symlinked as /usr/bin/X)

I've not checked cauldron, but I suspect it could be vulnerable.

Will try and do a bit more testing/packaging now.
Comment 25 David Walser 2012-09-27 01:00:22 CEST
Colin, do you know what the pam_systemd helper is exploiting in the PoC?
Comment 26 Colin Guthrie 2012-09-27 01:38:18 CEST
I believe it's the same deal as the Xorg one. i.e. su is setuid, and by virtue of su using PAM and the pam_systemd.so module using dbus, it can trigger the same thing. The "blah" binary doesn't actually need to run, so the fact it doesn't exists should be irrelevant.

I couldn't get it to work on mga2 (either the pam_systemd.so, or the Xwrapper binary) or cauldron (not fully up-to-date tho'). The spice-gtk one worked fine for me tho'.
Comment 27 David Walser 2012-09-27 02:04:10 CEST
(In reply to comment #26)
> I believe it's the same deal as the Xorg one. i.e. su is setuid, and by virtue
> of su using PAM and the pam_systemd.so module using dbus, it can trigger the
> same thing. The "blah" binary doesn't actually need to run, so the fact it
> doesn't exists should be irrelevant.
> 
> I couldn't get it to work on mga2 (either the pam_systemd.so, or the Xwrapper
> binary) or cauldron (not fully up-to-date tho'). The spice-gtk one worked fine
> for me tho'.

Thanks.  So either we're not vulnerable to that one, or the dbus update will fix it anyway.
Comment 28 claire robinson 2012-09-27 09:48:59 CEST
That would explain why it wasn't working :)

Testing dbus for regressions instead then. It has been fine, so testing complete mga2 64.
Comment 29 David Walser 2012-09-27 18:27:11 CEST
Mageia 1 subrel bumped.  Colin added a subrel line when there already was one.

Advisory:
========================

Updated dbus packages fix security vulnerability:

It was discovered that the D-Bus library honored environment settings even
when running with elevated privileges. A local attacker could possibly use
this flaw to escalate their privileges, by setting specific environment
variables before running a setuid or setgid application linked against the
D-Bus library (libdbus) (CVE-2012-3524).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3524
https://rhn.redhat.com/errata/RHSA-2012-1261.html
========================

Updated packages in core/updates_testing:
========================
dbus-1.4.1-3.2.mga1
libdbus-1_3-1.4.1-3.2.mga1
libdbus-1-devel-1.4.1-3.2.mga1
dbus-x11-1.4.1-3.2.mga1
dbus-doc-1.4.1-3.2.mga1
dbus-1.4.16-5.1.mga2
libdbus-1_3-1.4.16-5.1.mga2
libdbus-1-devel-1.4.16-5.1.mga2
dbus-x11-1.4.16-5.1.mga2
dbus-doc-1.4.16-5.1.mga2

from SRPMS:
dbus-1.4.1-3.2.mga1.src.rpm
dbus-1.4.16-5.1.mga2.src.rpm
Comment 30 Colin Guthrie 2012-09-27 18:35:48 CEST
(In reply to comment #29)
> Mageia 1 subrel bumped.  Colin added a subrel line when there already was one.

D'oh! Sorry. Strange tho', as it was submitted to the build system OK, it should have rejected it at the time no? Or perhaps I missed the failure due to the dbus builds spiralling out of control at the time...
Comment 31 David Walser 2012-09-27 19:10:37 CEST
(In reply to comment #30)
> (In reply to comment #29)
> > Mageia 1 subrel bumped.  Colin added a subrel line when there already was one.
> 
> D'oh! Sorry. Strange tho', as it was submitted to the build system OK, it
> should have rejected it at the time no? Or perhaps I missed the failure due to
> the dbus builds spiralling out of control at the time...

I've raised the issue with the sysadmins, but it hasn't been fixed.  It doesn't check to see if there's a newer or equal version in updates when you submit to updates_testing.
Comment 32 Dave Hodgins 2012-10-01 22:47:38 CEST
I haven't had much luck getting the poc to work, so I'm only testing for
regressions.

Testing complete on Mageia 1 i586 with the srpm
dbus-1.4.1-3.2.mga1.src.rpm

I'll test Mageia 1 x86-64 and Mageia 2 i586 shortly.
Comment 33 Dave Hodgins 2012-10-01 23:16:51 CEST
Testing complete.

Could someone from the sysadmin team push the srpm
dbus-1.4.16-5.1.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates and the srpm
dbus-1.4.1-3.2.mga1.src.rpm
from Mageia 1 Core Updates Testing to Core Updates.

Advisory: Updated dbus packages fix security vulnerability:

It was discovered that the D-Bus library honored environment settings even
when running with elevated privileges. A local attacker could possibly use
this flaw to escalate their privileges, by setting specific environment
variables before running a setuid or setgid application linked against the
D-Bus library (libdbus) (CVE-2012-3524).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3524
https://rhn.redhat.com/errata/RHSA-2012-1261.html

https://bugs.mageia.org/show_bug.cgi?id=7474
Comment 34 Thomas Backlund 2012-10-06 15:40:19 CEST
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0282

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