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.
Whiteboard: (none) => MGA2TOO, MGA1TOO
Created attachment 2794 [details] 0001-CVE-2012-3524-Don-t-access-environment-variables-or-.patch RedHat's patch.
Severity: normal => major
CC: (none) => mageia
CC: (none) => tmb
CC: (none) => dmorganec
CC: (none) => olav
CC: (none) => thierry.vignaud
CC: (none) => pterjan
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).
CC: (none) => oe
Here's the RedHat bug, with plenty more discussion on this: https://bugzilla.redhat.com/show_bug.cgi?id=847402
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.
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.
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
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
(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)...
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).
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)
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.
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
Assignee: bugsquad => qa-bugs
Colin, has this been fixed in Cauldron?
PoC: http://www.exploit-db.com/exploits/21323/
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..
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?
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.
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.
Oh, I forgot to say (in case it's not obvious), uninstall spice-gtk to get it to skip the spice helper.
Version: Cauldron => 2Whiteboard: MGA2TOO, MGA1TOO => MGA1TOO
Samuel, I'd like to get confirmation from Colin that Cauldron is not affected before changing the version.
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.
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?
CC: (none) => davidwhodgins
Whiteboard: MGA1TOO => MGA1TOO feedback
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.
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.
Colin, do you know what the pam_systemd helper is exploiting in the PoC?
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'.
(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.
That would explain why it wasn't working :) Testing dbus for regressions instead then. It has been fine, so testing complete mga2 64.
Hardware: i586 => AllWhiteboard: MGA1TOO feedback => MGA1TOO mga2-64-OK
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
(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...
(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.
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.
Whiteboard: MGA1TOO mga2-64-OK => MGA1TOO mga2-64-OK MGA1-32-OK
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
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsWhiteboard: MGA1TOO mga2-64-OK MGA1-32-OK => MGA1TOO mga2-64-OK MGA1-32-OK MGA1-64-OK MGA2-32-OK
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0282
Status: NEW => RESOLVEDResolution: (none) => FIXED