Bug 1036245 (CVE-2017-8849)

+++ This bug was initially created as a clone of Bug #1036244 +++

This document describes a generic root exploit against KDE.

The exploit is achieved by abusing a logic flaw within
the KAuth framework which is present in KDE4 (org.kde.auth) and KDE5
(org.kde.kf5auth). It is possible to spoof what KAuth calls
callerID's which are indeed DBUS unique names of the sender of a DBUS message.
Exploitation requires a helper which is doing some privileged work
as root. For this document I chose smb4k because it contains
another vulnerability that makes exploitation a lot easier;
but in general any KAuth privileged helper code can be triggered
by users with arbitrary arguments.

I will describe the overall problem by walking through the smb4k code and explain
which DBUS functions are called and how a particular smb4k bug maps
into the bigger picture of the KAuth flaw.

Theres a problem with smb4k using the KAuth framework
and trusting all the arguments passed to the helper:

ActionReply Smb4KMountHelper::mount(const QVariantMap &args)
{

...

command << args["mh_command"].toString();
command << args["mh_unc"].toString();
command << args["mh_mountpoint"].toString();
command << args["mh_options"].toStringList();

...

proc.setProgram(command);
// Run the mount process.
proc.start();
...
}

This code is running as root, triggered via DBUS activation by smb4k GUI code
running as user, and the "args" supplied by the user, via:

void Smb4KMountJob::slotStartMount()
{
...
      Action::executeActions(actions, NULL, "net.sourceforge.smb4k.mounthelper");
...

after filling "actions" (theres only one) with the proper Name
(net.sourceforge.smb4k.mounthelper.mount) and HelperID
(net.sourceforge.smb4k.mounthelper) in order to trigger DBUS activation as well as
the argument dictionary which contains the "mh_command" etc. key/value pairs.
(Its calling the list-version of Action::executeAction() [note the
trailing 's'] with a one-element list. But that doesnt matter.)
The important thing here is that the arguments are created by code
running as user, potentially containing evil input, and are evaluated
by the helper program running as root.

The above call ends at DBusHelperProxy::executeAction(), still at callers side.
This function translates it into a DBUS method call thats
finally running privileged, whos interface is this:

<interface name="org.kde.kf5auth">
    <method name="performAction" >
        <arg name="action" type="s" direction="in" />
        <arg name="callerID" type="ay" direction="in" />
        <arg name="arguments" type="ay" direction="in" />
         <arg name="r" type="ay" direction="out" />
     </method>
...

Unlike the smb4k mount helper DBUS interface itself, which isnt
accessible as user, KAuth DBUS (org.kde.kf5auth) is:

<busconfig>
  <policy context="default">
    <allow send_interface="org.kde.kf5auth"/>
    <allow receive_sender="org.kde.kf5auth"/>
    <allow receive_interface="org.kde.kf5auth"/>
  </policy>
</busconfig>

The code for actually doing the call from user to root is this:

void DBusHelperProxy::executeAction(const QString &action, const QString &helperID, const QVariantMap &arguments)
{
...
QDBusMessage::createMethodCall(helperID, QLatin1String("/"), QLatin1String("org.kde.kf5auth"), QLatin1String("performAction"));

QList<QVariant> args;
args << action << BackendsManager::authBackend()->callerID() << blob;
message.setArguments(args);

m_actionsInProgress.push_back(action);

QDBusPendingCall pendingCall = m_busConnection.asyncCall(message);

...

with the user supplied (created by smb4k when running as user)
arguments dictionary attached to the DBUS message, passing along the
potentially evil "mh_command" key.

There are two problems:

The KAuth frameworks "performAction" method is passed the callerID by the user
and the method is invokable by the user. This allows to mask as any caller,
bypassing any polkit checks that may happen later in the KAuth polkit backend
via PolicyKitBackend::isCallerAuthorized(const QString &action, QByteArray callerID).
The second problem is smb4k trusting the arguments that are passed from the user and which
are forwarded by the KAuth DBUS service running as root to the mount helper
DBUS service which is also running as root but not allowed to be contacted by users.
Thats a logical flaw. It was probably not expected that users invoke
"performAction" themself, using it as a proxy into DBUS services and
faking caller IDs en-passant. The callerID usually looks like ":1.123"
and is a DBUS unique name that maps to the sender of the message.
This ID should be obtained via a DBUS function while the message is arriving,
so it can actually be trusted and used as a subject for polit authorizations
when using systembus-name subjects. Allowing callers to freely specify this ID
is taking down the whole idea of authentication and authorization.

I made an exploit for smb4k that works on openSUSE Leap 42.2 thats using the org.kde.auth
interface (rather than the new org.kde.kf5auth) but both interfaces
share the same problems. In order to test the callerID spoofing,
I "protected" the smb4k helper code via "auth_admin" polkit settings and
tried mounting SMB shares via smb4k GUI. This asked for the root password,
as its expected. The exploit however still works, as its spoofing the callerID
to be DBUs itself and the request is taken as legit.