Bug 7595 - glib2.0 new security issue CVE-2012-3524
: glib2.0 new security issue CVE-2012-3524
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: i586 Linux
: Normal Severity: major
: ---
Assigned To: QA Team
:
: http://lwn.net/Vulnerabilities/516077/
: has_procedure mga2-64-OK MGA2-32-OK
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2012-09-27 02:15 CEST by David Walser
Modified: 2012-10-14 21:16 CEST (History)
5 users (show)

See Also:
Source RPM: glib2.0
CVE:


Attachments

Description David Walser 2012-09-27 02:15:11 CEST
Fedora has issued an advisory on September 17:
http://lists.fedoraproject.org/pipermail/package-announce/2012-September/088257.html

glib2.0 is OK in Cauldron, as it's fixed in 2.33.14.

This is related to Bug 7474 and Bug 7536.

The suggested patch to fix this was here, probably the same Fedora used:
https://bugzilla.redhat.com/show_bug.cgi?id=847402

Colin Guthrie has applied the glib2.0 patch to our package in updates_testing,
but the version there is newer than what we shipped in Mageia 2, because Olav
Vitters is still preparing an update to the glib/gtk/gnome stack in Mageia 2.

Either the Mageia 2 SVN branch needs to be reverted to the branched version and
the patch applied there, or we need to decide it's OK to update glib now, or
something else.  In the meantime, here's the version currently built in
updates_testing.

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 1 Colin Guthrie 2012-09-27 09:26:33 CEST
OK, so is there a decision on this? Should we be updating the older version, or pushing the newer one. If the older, I'll take a look at that today.
Comment 2 Olav Vitters 2012-09-27 19:21:50 CEST
I'm fine with anything:
 - removing the thing from updates_testing
 - shipping a newer glib
Comment 3 David Walser 2012-10-04 23:17:16 CEST
I think we can push this to QA.  We just need an advisory.
Comment 4 Colin Guthrie 2012-10-05 00:14:28 CEST
Yeah I think there was general consensus on IRC and with the folk I poked about it. Go for it. I'd say just copy+paste the advisory from the other bugs and just mention that we've also updated our version to fix various bugs.
Comment 5 David Walser 2012-10-10 00:41:35 CEST
Colin, could you give a better description of what the patch to glib2.0 fixes?

It looks to me like it's not running external commands as root when running within a SUID root program and stripping out certain environment variables in certain situations, but that's as best I can come up with.  The other advisory descriptions talk about dbus and spice-gtk specifically.  This is related to those issues, but I don't think just copying those advisories is clear enough about what this is fixing.
Comment 6 Colin Guthrie 2012-10-10 11:30:43 CEST
The upstream commit probably describes it best:
http://git.gnome.org/browse/glib/commit/?id=d6cbb29f598d677d5fc1c974cba6d9f646cff491

Basically, because glib implements it's own libdbus-esque functionality to start things via dbus-launch, it could be tricked in the same way as libdbus into starting a rogue application as route if the glib application was setuid.

The critical bit from the above commit message (and the bit that the exploit program exploited) is:

"ensure we don't run an external dbus-launch binary if DBUS_SESSION_BUS_ADDRESS isn't set."

So my stab at some advisory text would be:



It was discovered that the version of glib shipped with Mageia 2 does not sanitise certain DBUS related environment variables. When used in combination with a setuid application which utilises dbus via glib, a local user could gain escalated privileges with a specially crafted environment.

Thus updated version of glib adds appropriate protection against such scenarios and also adds additional hardening when used in a setuid environment.

Note: Mageia 1 did not ship any setuid glib applications and thus has not been included in this update.
Comment 7 David Walser 2012-10-10 12:20:41 CEST
Thanks Colin!  Assigning to QA.

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

Updated glib2.0 packages fix security vulnerability:

It was discovered that the version of glib shipped with Mageia 2 does not
sanitise certain DBUS related environment variables. When used in
combination with a setuid application which utilises dbus via glib, a local
user could gain escalated privileges with a specially crafted environment.
This is related to a similar issue with dbus (CVE-2012-3524).

This updated version of glib adds appropriate protection against such
scenarios and also adds additional hardening when used in a setuid
environment.

Note: Mageia 1 did not ship any setuid glib applications and thus has not
been included in this update.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3524
http://lists.fedoraproject.org/pipermail/package-announce/2012-September/088257.html
========================

Updated packages in core/updates_testing:
========================
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 claire robinson 2012-10-11 17:31:22 CEST
Not really sure how to test this one.

The PoC from bug 7474 can be used but after doing chmod u+s /usr/bin/Xorg building commenting the elsif to do with pam_systemd with /* and */ all I've succeeded in doing is hard locking the computer.

libglib2.0_0 is required by pretty much everything though so perhaps just testing 'things' seem to work ok after updating would be enough.

Any thoughts?
Comment 9 claire robinson 2012-10-11 17:35:13 CEST
pretty much everything == anything remotely gtk
Comment 10 Colin Guthrie 2012-10-11 17:38:19 CEST
@Claire as I mentioned on one of the other bugs I suspect the Xorg helper on Mageia is actually /usr/bin/Xwrapper not /usr/bin/Xorg, but regardless, this is not the part of the exploit that would be affected by this update. Basically ignore the Xorg and systemd parts of the exploit here, as neither of them use glib.

The only part of the exploit that would be fixed here is the spice-gtk ACL helper utility. It uses glib to talk to dbus. Keep in mind though that spice-gtk has already been fixed separately to avoid the exploit path so you'll have to ensure you have the original spice-gtk from mga2 installed, not the updated one for the exploit to work.

This should test that the exploit path itself is fixed (i.e. upgrading *either* spice-gtk or glib should prevent the exploit).

Other than that, yes, general testing of glib before pushing the update is certainly wise!!

HTHs
Comment 11 claire robinson 2012-10-11 17:59:18 CEST
Thanks Colin, that gives us some direction!

It does ring a bell now that you mention it.
Comment 12 claire robinson 2012-10-11 18:16:31 CEST
# urpmi --media Release spice-gtk

installing spice-gtk-0.9-1.mga2.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     #############################
      1/1: spice-gtk             #############################



Using the PoC from here: http://www.exploit-db.com/exploits/21323/


Editting the path of spice-gtk-helper in the PoC

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

Before
------

$ gcc 21323.c
$ ./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/testing.txt
bash-4.2# ls -l /root/testing.txt
-rw-r--r-- 1 root claire 0 Oct 11 17:07 /root/testing.txt
bash-4.2# exit
exit


After
-----
# urpmi glib2.0_0-common lib64glib2.0_0 lib64gio2.0_0 glib-gettextize

To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch
(medium "Core Updates Testing")
  glib-gettextize                2.32.4       1.1.mga2      x86_64
  glib2.0-common                 2.32.4       1.1.mga2      x86_64
  lib64gio2.0_0                  2.32.4       1.1.mga2      x86_64
  lib64glib2.0-devel             2.32.4       1.1.mga2      x86_64
  lib64glib2.0_0                 2.32.4       1.1.mga2      x86_64

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

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

Interrupted it with ctrl-c when it failed to produce a root shell.

Checked for regressions with a few gtk apps (Shotwell, Firefox etc)

# urpme spice-gtk


Testing complete Mageia 2 x86_64
Comment 13 Dave Hodgins 2012-10-13 22:19:21 CEST
Thanks for the procedure Claire.  Testing complete Mageia 2 i586.

Could someone from the sysadmin team push the srpm
glib2.0-2.32.4-1.1.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates.

Advisory: Updated glib2.0 packages fix security vulnerability:

It was discovered that the version of glib shipped with Mageia 2 does not
sanitise certain DBUS related environment variables. When used in
combination with a setuid application which utilises dbus via glib, a local
user could gain escalated privileges with a specially crafted environment.
This is related to a similar issue with dbus (CVE-2012-3524).

This updated version of glib adds appropriate protection against such
scenarios and also adds additional hardening when used in a setuid
environment.

Note: Mageia 1 did not ship any setuid glib applications and thus has not
been included in this update.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3524
http://lists.fedoraproject.org/pipermail/package-announce/2012-September/088257.html

https://bugs.mageia.org/show_bug.cgi?id=7595
Comment 14 Thomas Backlund 2012-10-14 21:16:32 CEST
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0293

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