[Pkg-utopia-maintainers] Bug#689070: Please take upstream D-Bus patches for CVE-2012-3524

[Simon McVittie]

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