Package: acpi-support-base
Version: 0.142-2
Severity: important
As a D-Bus maintainer upstream and in Debian, I was alarmed to see this
security notification for the bug fixed in acpi-support 0.142-2:
> CESG discovered a root escalation flaw in the acpi-support package.
> An unprivileged user can inject the DBUS_SESSION_BUS_ADDRESS environment
> variable to run arbitrary commands as root user via the policy-funcs
> script.
My first thought was: "What on earth is acpi-support doing on individual
users' session buses anyway? The system bus is the place for system services
to communicate". So I looked at the diff between acpi-support 0.142-1
and 0.142-2.
That particular vulnerability turned out to be in CheckPolicy, which
appears to be intended to answer the question: does acpi-support need
to handle this particular event, or has someone else taken responsibility?
In order to answer that, it appears to be rummaging in /proc/$pid/environ
to find users' DBUS_SESSION_BUS_ADDRESSes, then using su and dbus-send
from shell script to probe their sessions. This seems rather error-prone.
Other parts of acpi-support inject events into users' X11 sessions
by fishing their DISPLAY and XAUTHORITY out of random processes'
environments, su'ing to the appropriate user and running shell commands.
I realise that the vulnerability is not *directly* related to those
practices, but still...
Here are some recommendations, with low hanging fruit first:
* Probe for HasLogindAndSystemd1Manager first, before even looking
for the X11 user. This check can be done at a purely system-wide level,
without involving yourself with individual users. Also, systemd-logind
is meant to be installed by default in Debian 8, and is increasingly
depended-on by desktop environments anyway, so this check will often
succeed, short-circuiting the scarier logic.
* Consider checking only for the presence of systemd-logind, not
for its ability to shut down. That would be significantly simpler,
and in the unlikely event that systemd-logind is running but the sysadmin
has explicitly configured it to not do power management, it seems
undesirable for acpi-support to jump in and do it instead.
* Modern GNOME relies on systemd-logind for suspend/hibernate/shutdown,
so don't dbus-send to it, and perhaps don't check for its processes
either; either systemd-logind will do the job, or GNOME won't.
Also, as with systemd-logind, in the unlikely event that the logged-in
user has explicitly configured GNOME to not load the Power plugin,
it seems undesirable for acpi-support to jump in and do it.
* I believe modern KDE relies on systemd-logind too; I don't use it,
but the KDE maintainers would know.
* KDE no longer appears to have dcop, so avoid "/usr/bin/dcop --user $XUSER";
if you want to support obsolete KDE, avoid that anyway, unless dcop has
been audited and is specifically safe for root to use like this.
* Does acpi-support do anything on systems where CheckPolicy succeeds?
If not, and the intention is for it to be what's installed by people who
don't install GNOME, KDE, systemd, etc. and prefer to run fvwm or
something, perhaps it should not be part of the laptop task,
or that task should depend on systemd-sysv | acpi-support or some such,
since Debian 8 is presumably going to install systemd-sysv by
default anyway?
* I would strongly recommend that system services follow a model where
the system service exists only at system level and does not do
su, X11, interact with the session bus, etc., and it is up to the
user session to connect to the system bus and ask to be notified
by system services. However, I recognise that there's a bit of a chicken/egg
situation here: the major desktop environments do already use that design,
with things like upower and systemd-logind as the system service with
which they communicate, leaving acpi-support to try to support
environments where the user session doesn't have any support for
doing that.
Regards,
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
