KDE kauth and kdelibs Logic Flaw Lets Local Users Obtain Root Privileges(CVE-2017-8422)

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 D-Bus unique names of the sender of a D-Bus message. Exploitation requires a helper which is doing some privileged work as root. Kde ships quite some of them, but for this writeup I chose the smb4k helper 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 which leads to LPE on default kde installations.

I will describe the overall problem by walking through the smb4k code and explain which D-Bus 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 D-Bus 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 D-Bus 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 doesn’t 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 D-Bus method call which is finally running privileged and has the following interface:

<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>
...
</interface>

Unlike the root helpers D-Bus interfaces itself, which are not accessible as user, the KAuth D-Bus interface 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);

...
}

This code is invoking the performAction() D-Bus method, passing along the user supplied arguments dictionary, in our smb4k case containing the handcrafted evil mh_command key, amongst others key/value pairs.

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 calls into

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 D-Bus service running as root to the mount helper D-Bus service which is also running as root but not allowed to be contacted by users. Thats a logical flaw. It was probably not intented that users invoke performAction() themself, using it as a proxy into D-Bus services and faking caller IDs en-passant. The callerID usually looks like :1.123 and is a D-Bus unique name that maps to the sender of the message. You can think of it like the source address of an IP packet. This ID should be obtained via a D-Bus function while the message is arriving, so it can actually be trusted and used as a subject for polkit authorizations when using systembus-name subjects. Allowing callers to arbitrarily choosing values for 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 org.kde.kf5auth) but both interfaces share the same problems. The exploit also works on the latest Fedora26 Alpha kde spin with SELinux in enforcing mode. 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 D-Bus itself and the request is taken as legit, requiring no root password.