On Fri, 28 Sep 2012 at 14:30:37 -0700, Geoffrey Thomas wrote:
> CVE-2012-3524 is about setuid binaries linking libdbus being easily
> trickable to do bad things via a malicious PATH (for finding
> dbus-launch), or through a DBUS_* address variable using the
> unixexec address type.
This also affects reimplementations of D-Bus, most prominently GDBus
in GLib; src:dbus can't do anything to help those.
I believe the libdbus part of this CVE affects wheezy and certain unusual
squeeze configurations. The known vectors for privilege escalation are:
* tell libdbus (explicitly or via it being the session-bus default) to
connect to autolaunch: which results in it exec'ing dbus-launch;
have it not find dbus-launch in its configured ${bindir};
have it find a malicious dbus-launch substitute in its $PATH
* tell libdbus to connect to unixexec:something-malicious
The former is only exploitable if there is no ${bindir}/dbus-launch.
On some distributions, D-Bus is configured with ${prefix} = /, but
dbus-launch is moved to /usr/bin by the packager because it depends on libX11.
As a result, libdbus tries /bin/dbus-launch, never finds it, and falls
back to searching the $PATH, where it hopefully finds /usr/bin/dbus-launch.
However, on Debian, we do the opposite: configure D-Bus with ${prefix} = /usr,
and move libdbus-1.so.3 into /lib in the packaging. As a result, the only
way to not find dbus-launch in /usr/bin is if you have libdbus-1-3 but not
dbus-x11. This mitigates the attack somewhat.
> Initially the D-Bus developers thought that
> this should be fixed on the application side (hence the comment in
> the security-tracker), but decided that it would be better to have a
> defense-in-depth approach, and change _dbus_getenv to not succeed if
> the current program is setuid or similar, since that's faster than
> patching every relevant program.
I still think this is an application bug - it's the application that
knows it is (or claims to be) setuid-safe - but yes, we should do both.
S
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
