Shell expansion may allow privilege boundary crossing

sbeattie suggested that su command could be changed to the following:

su - $XUSER -c 'eval $(echo -n "export "; grep -z DBUS_SESSION_BUS_ADDRESS /proc/$(pidof kded4)/environ); qdbus org.kde.kded'

In the attack scenario, this causes the grep command to fail due to $XUSER not having permission to read /proc/$(pidof kded4)/environ. However, we may want to clean this up a little more because qdbus is still executed. sbeattie also pointed out that $(pidof kded4) returning multiple pids could be problematic.

Proposed fix for powerbtn.sh

The Debian Security Team has been notified of this issue and they have received the proposed fix.

Final version of the patch.

This bug was fixed in the package acpid - 1:2.0.10-1ubuntu3

---------------
acpid (1:2.0.10-1ubuntu3) precise; urgency=low

  * SECURITY UPDATE: Arbitrary code execution in the power button handling
    script (LP: #893821)
    - debian/powerbtn.sh: Ensure that the DBUS_SESSION_BUS_ADDRESS environment
      variable is only read from a process owned by the user that will be
      evaluating the variable.
    - CVE-2011-2777
  * SECURITY UPDATE: Unprivileged users may be able to write to directories
    and read files created by event handler scripts
    - event.c: Set a restrictive umask of 0077 before running an event handler
      script. Based on upstream patch.
    - CVE-2011-4578
 -- Tyler Hicks <email address hidden> Wed, 07 Dec 2011 16:33:35 -0600

Thanks again for your cooperation and assistance, otr!

> sbeattie also pointed out that $(pidof kded4) returning
> multiple pids could be problematic.
And that's true.

For example, if I use ssh to access a remote machine, which is using KDE:
    ganton@t1:~$ pidof kded4
    12511 1382
those were two results returned.

For more information:
    ganton@t1:~$ ps aux | grep [1]2511
    root 12511 0.0 0.8 79700 5300 ? S Dec06 0:07 kdeinit4: kded4 [kdeinit]
    ganton@t1:~$ ps aux | grep [1]382
    ganton 1382 0.0 7.1 266424 45632 ? Sl Dec06 0:43 kdeinit4: kded4 [kdeinit]
we see that there are two process named "kded4", one for "root" and another for the user "ganton".

But if something like "pgrep -u" is used:
    ganton@t1:~$ pgrep "kded4" -u "$USER"
    1382
there is no "two results returned" problem.

I suggest changing those "pidof" that appear in the code (for example, in the patch).

Thanks for the work!

For more information:
    The "cat /proc/[...]/environ" method that is used now there... is said to cause problems:
    - "you have multiple hosts"
    - "when more than one X session is used"
    - etc.

    In those two site talk more about it:
        http://www.rootninja.com/dbus-session-bus-address-with-applications-using-ssh/
        http://machine-cycle.blogspot.com/2010/12/ssh-and-dbus-sessions.html

On 2011-12-09 08:36:20, Ganton wrote:
> I suggest changing those "pidof" that appear in the code (for example,
> in the patch).

Thanks for the suggestion, Ganton. The update did make the change from
pidof to pgrep. The script's new usage of pgrep uses the -n and -u
options.

On 2011-12-09 09:27:50, Ganton wrote:
> For more information:
> The "cat /proc/[...]/environ" method that is used now there... is said to cause problems:
> - "you have multiple hosts"
> - "when more than one X session is used"
> - etc.

That's a good point. However, this was strictly a security update that
focused on preventing powerbtn.sh from being fooled into executing code
provided by another user.

Completely changing how the DBUS session bus address is retrieved in all
of the ACPI scripts was outside of the scope for this update. You may
want to consider opening a separate bug for the issue you raised.