Category: KDE

You might have noticed that my yesterday’s blog post was an April Fool. With this post I want to explain a little bit about the idea of the article.

First of all I want to thank the VDG, especially Jens and Ken, for their support by providing the great mockups. That was kind of the first element to notice that it’s an April Fool: normally I do only integrate screenshots by myself and I would not have been able to show a drawing in Krita.

The idea for this April Fool is based on the reports about the inclusion of an adware tool called superfish on Lenovo notebooks. Especially the initial response by Lenovo claiming that this malicious software got installed “to improve the shopping experience”.

Nevertheless the article contains truth, half truth and thing we would never do. So let’s look at some of the ideas presented and evaluate them. The first idea presented was share buttons integrated in the browser’s window decoration. This is an idea which already got introduced similarily through Share-Like-Connect. Personally I think it’s a good idea if browsers would provide such global buttons and in return filter out all the user tracking share buttons on the web sites. A global area for share buttons directly integrated in the browser could increase the security of users a lot.

The next idea is about monitioring the usage behavior of the user. For this I must say that in a Wayland world KWin would have enough information to do that, but we don’t look at the information at all. We do not care what an application is: we don’t know that a given window is “Krita”, we don’t know that it should be used with a drawing tablet, we don’t analyze any input and just pass it through to the application. KWin is completely ignorant on what the application does with input events passed to them and as ignorant to what a window content looks like. To us a window is just a texture we render to the screen. We don’t know that there is a “drawing area” or a “video” element, it’s just one texture. Similarly we do not know (and care) about input events. All we do is determine which window should get the event and pass it to it. We are quite aware that by passing all input events through KWin we could do evil things. The good thing is that our software is open source and you can see what we do (relevant code file is called input.cpp, events come in from the files under the libinput/ directory).

Last but not least I want to point out that we as a window manager will not integrate advertisement into the window management. We do not care whether you watch a video, we might not even know it, because as explained: we are ignorant about what you do. I consider applications which integrate advertisement without the user’s explicit acknowledgement as malware.

The bad part of my blog post is that I expect these things to happen. And if we look around us we can see that it already happened: adware is unfortunately also available in FLOSS. And in the walled garden’s of the proprietary world we will see more attempts to gain more information about the user’s to provide even better matching advertisement. It will blur more and more.

Today we released Plasma 5.2 and this new release comes with two fixes for security vulnerabilities in our screen locker implementation. As I found, exploited, reported and fixed these vulnerabilities I decided to put them a little bit into context.

The first vulnerability concerns our QtQuick user interface for the lock screen. Through the Look and Feel package it was possible to send the login information to a remote location. That’s pretty bad but luckily also only a theoretical problem: we have not yet implemented a way to install new Look and Feel packages from the Internet. So we found the issue before any harm was done.

The second vulnerability is more interesting as it is heavily related to the usage of X11 by the screen locker. To put this vulnerability into context I want to discuss screen lockers on X11 in general. In a previous post I explained that a screen locker has two primary tasks:

1. Blocking input devices, so that an attacker cannot interact with the running session
2. Blanking the screen to prevent private information being leaked

From the first requirement we can also derive a requirement that no application should get the input events except the lock screen and that the screen gets locked after a defined idle time. And from the second requirement we can derive that no application should have access to any screen content while the screen is being locked.

With these extended requirements we are already getting into areas where we cannot have a secure screen locker on X11. X11 is too old and too insecure to make it possible to fulfill the requirements. Why is that the case?

X11 on a protocol level doesn’t know anything of screen lockers. This means there is no privileged process which acts as the one and only screen locker. No, a screen locker is just an X11 client like any other (remote or local) X11 client connected to the same X server. This means the screen locker can only use the core functionality available to “emulate” screen locking. Also the X server doesn’t know that the screen is locked as it doesn’t understand the concept. If the screen locker can only use core functionality to emulate screen locking then any other client can do the same and prevent the screen locker from locking the screen, can’t it? And yes that is the case: opening a context menu on any window prevents the screen locker from activating.

That’s quite a bummer: any process connected to the X server can block the screen locker. Even more it could fake your screen locker. How hard would that be? Well I asked that question myself and needed about half an hour to implement an application which looks and behaves like the screen locker provided by Plasma 5. This is so trivial that I don’t see a point in not sharing the code:

#include <QGuiApplication>
#include <QQuickView>
#include <QQmlContext>
#include <QScreen>
#include <QStandardPaths>
#include <QtQml>

class Sessions : public QObject
{
    Q_OBJECT
    Q_PROPERTY(bool startNewSessionSupported READ trueVal CONSTANT)
    Q_PROPERTY(bool switchUserSupported READ trueVal CONSTANT)
public:
    explicit Sessions(QObject *parent = 0) : QObject(parent) {}
    bool trueVal() const { return true; }
};

int main(int argc, char **argv)
{
    QGuiApplication app(argc, argv);

    const QString file = QStandardPaths::locate(QStandardPaths::GenericDataLocation,
        QStringLiteral("plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreen.qml"));

    qmlRegisterType<Sessions>("org.kde.kscreenlocker", 1, 0, "Sessions");
    QQuickView view;
    QQmlContext *c = view.engine()->rootContext();
    c->setContextProperty(QStringLiteral("kscreenlocker_userName"),
                          QStringLiteral("Martin Graesslin"));
    c->setContextProperty(QStringLiteral("kscreenlocker_userImage"), QImage());
    view.setFlags(Qt::BypassWindowManagerHint);
    view.setResizeMode(QQuickView::SizeRootObjectToView);
    view.setSource(QUrl::fromLocalFile(file));
    view.show();
    view.setGeometry(view.screen()->geometry());
    view.setKeyboardGrabEnabled(true);
    view.setMouseGrabEnabled(true);

    return app.exec();
}

#include "main.moc"

This looks like and behaves like the real screen locker, but it isn’t. A user has no chance to recognize that this is not the real locker. Now if it’s that simple to replace the screen locker why should anyone go a complicated way to attack the lock screen? At least I wouldn’t.

And is there nothing which could be done to protect the real locker? Well obviously a good idea is to mark the one and only screen locker as authentic. But how to do that in a secure way on X11? We cannot e.g. show a specific user selected image. This would conflict with another problem with screen lockers on X11: it’s not possible to prevent that other windows grab screen content. So whatever the screen locker displays is also available to all other X11 clients. Also the window manager cannot help like preventing fullscreen windows to open fullscreen as can be seen in the code fragment above: it’s possible to bypass the window manager. Built in feature by X11.

Many of these issues could be considered as non-problematic using the old pragma of “if it runs, it’s trusted”. While I personally disagree, it just doesn’t hold for X11. If only clients of one user were connected to the X server one could say so. But X11 allows clients from other users and even remote clients. And this opens a complete new problem scope. Whenever you use ssh -X you open up your local system to remote attack vectors. If you don’t control the remote side it could mean that the client you start is modified in a way to prevent your screen from locking or to install a fake locker. I know that network transparency is a feature many users love, but it’s just a security night mare. Don’t use it!

Overall we see that attacking a screen locker or preventing that it opens up is really trivial on X11. That’s an inherent problem on the architecture and no implementation can solve them, no matter what the authors tell how secure it is. Compared to these basic attack vectors the vulnerability I found is rather obscure and it takes a considerable amount of understanding how X11 works.

Nevertheless we fixed the issue. And interestingly I chose to use the technology which will solve all those problems: Wayland. While we don’t use Wayland as the windowing system we use a custom domain-specific Wayland-based protocol for the communication between the parts our screen locker architecture. This uses the new libraries developed for later usage in kwin_wayland.

As we are speaking of Wayland: how will Wayland improve the situation? In the case of Plasma the screen locker daemon will be moved from ksmserver to kwin, so that the compositor has more control over it. Screen locking is a dedicated mode supported by the compositor. Whether a context menu is open or not doesn’t matter any more, the screen can be locked. Also the compositor controls input events. If it has the knowledge that the screen is locked, it can ensure that no input goes to the wrong client. Last but not least the compositor controls taking screenshots and thus can prevent that clients can grab the output of the lock screen.

With the 5.2 release basically done, I decided to do some performance investigation and optimizations on KWin last week. From time to time I’m running KWin through valgrind’s callgrind tool to see whether we have some expensive code paths. So far I hadn’t done that for the 5.x series. Now after the switch to kdecoration2 I was really interested in the results as in the past rendering the decoration used to be a bottle neck during our compositing rendering loop.

Unfortunately callgrind doesn’t give us a good look on the performance of KWin as it neither includes GPU times nor roundtrips to the X server. Nevertheless it gives us a good look on our own CPU usage. I was rather surprised by the result as I didn’t find anything which looked bad. Nevertheless I was able to slightly optimize one method which is called whenever the X11 stacking order is changed by improving an internal algorithm which didn’t scope well with the larger than expected number of child windows of the root window.

But callgrind output wasn’t the only performance relevant thing I looked into. I investigated a really interesting bug report about the screen freezing for a short time when a new window opened. While I wasn’t able to reproduce the issue as is, I was able to reproduce a small freeze whenever a Qt 5 application opened. Interestingly only with a Qt 5 application. So I ran the same application in a Qt 4 and Qt 5 variant and only in the latter I got a freeze. Investigation showed pretty quick that KWin is not to blame, for one I got the freeze before KWin started to manage a window for it and I was able to reproduce with different window managers. With the help of xtrace I finally found the culprit and we found the appropriate bug report on Qt side. Also our KDE domain experts started to look into the issue on Qt side.

But still others were able get a small freeze whenever KWin started to manage a window. And in deed further investigation showed that the method handling the managing of a new window can take some time and can cause the compositor to drop frames. Ideally this would be solved by moving the compositor into a dedicated rendering thread but that’s quite a lot of work and might not help in that case as KWin’s main thread grabs the XServer while managing a window. So the better solution was to investigate why the method takes so long. To not drop any frames the method may not take longer than 16 msec, the shorter the better.

While managing a window KWin needs to read quite a lot of properties. Most of them are nicely read in a non-blocking way through the KWindowSystem framework, but some properties are also KWin internal and read in a blocking way. Most expensive was reading the icons which was triggering several round trips especially if the window did not specify the icons in a NETWM compliant way. This could easily cause a delay of 50 to 100 msec during managing a window. Overall the method could trigger up to 14 round trips to the X server which were not needed at all in the case of KWin. Our KWindowSystem framework got an adjustment to prevent the roundtrips if the user of the KWindowSystem framework has all required information already fetched. The result is that reading the icons is now significantly below one msec. For other roundtrip causing methods I introduced two new methods: one to perform the request, one to later read the result. This allowed to remove another set of roundtrips. My measurements showed that each roundtrip takes about half a millisecond on my system. Half an msec here, half an msec there easily adds. Unfortunately there are still some XLib calls (one to read motif hints and one to read WM_SIZE_HINTS) which ideally would get ported and as long as they are not ported delay the managing of a new Client.

Nevertheless this shows quite some nice improvements for our development version which will become 5.3 in a few months. Of course all of that would not have been possible without the switch from XLib to XCB.