document that setuid executables must clear their environment before using libdbus
Submitted by Simon McVittie
Assigned to D-Bus Maintainers
Description
(This issue was raised and made public on oss-sec, but for some reason not upstream. By coincidence, I was subscribed to oss-sec as a result of helping to deal with ioquake3 security.)
libdbus obeys various environment variables retrieved using getenv(). This is a potential vulnerability if a set*id application links libdbus, uses libdbus in a way that obeys environment variables, and trusts that the values of those environment variables, or the D-Bus addresses to which they point, are trustworthy.
The example cited in the Novell bug is Xorg, which is apparently setuid on SUSE, linking libhal (under at least some configurations), which uses the system bus. If Xorg makes policy decisions using PolicyKit or by calling GetConnectionUnixUser or equivalent on dbus-daemon, then a malicious user could run Xorg with DBUS_SYSTEM_BUS_ADDRESS in its environment, connecting it to a bus that answers GetConnectionUnixUser dishonestly or contains a dishonest PolicyKit implementation, which induces it to make wrong policy decisions.
When I say "set*id" I mean setuid, setgid, or any analogous executable-based privileges that allow a caller to provide the initial environment while escalating privileges (e.g. Linux VFS capabilities).
Mitigations include:
-
Most system services don't use the system bus.
-
System services started by service activation (like PolicyKit itself) never need to be setuid, because dbus-daemon-launch-helper starts them with appropriate privileges anyway.
-
System services started by init (sysvinit, systemd, Upstart or equivalent) never need to be setuid, because their init scripts (or equivalent) are fully-privileged anyway.
References:
https://bugzilla.novell.com/show_bug.cgi?id=697105 http://seclists.org/oss-sec/2012/q3/29
Version: 1.5