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.

I'm fine with anything:
 - removing the thing from updates_testing
 - shipping a newer glib

I think we can push this to QA.  We just need an advisory.

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.

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.

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.

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

CC: (none) => olav
Assignee: olav => qa-bugs

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?

pretty much everything == anything remotely gtk

@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

Thanks Colin, that gives us some direction!

It does ring a bell now that you mention it.

# 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

Whiteboard: (none) => mga2-64-OK

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

Keywords: (none) => validated_update
CC: (none) => davidwhodgins, sysadmin-bugs
Whiteboard: has_procedure mga2-64-OK => has_procedure mga2-64-OK MGA2-32-OK

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0293

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED