Security

Desktop malware risk gets raised and patched

One of the most common claims about GNU/Linux is that it is supposed to be relatively immune to viruses and malware. However, for the past few weeks, that claim has been more closely scrutinized, thanks to a blog posting by "foobar" entitled "How to write a Linux virus in 5 easy steps." Specifically, the posting gives a high-level explanation of how malware can take advantage of the behavior of application launchers on the GNOME and KDE desktops to infect a user account — and possibly gain root access as well. The result has been endless Internet discussions and coordinated efforts by both GNOME and KDE to minimize the problem.

The method described by foobar depends on social engineering: That is, manipulating users into saving an attachment to their GNOME or KDE desktop, and then into executing it. Ordinarily, foobar points out, a saved email attachment would not have executable permission. However, GNOME and KDE share a common format for desktop launchers (*.desktop), and allows them to run without an executable flag. This exception makes it easy to run a script (foobar suggests Python as a likely language) that will download a piece of malware, especially since a custom icon and name can disguise the nature of the program that the launcher runs. Furthermore, by adding a link in the desktop environment's autostart directory, the malware can then run each time that a user logs into the account.

From the perspective of security architecture, gaining root access is considered the goal of malware. However, foobar emphasizes that the method described can do damage without logging into the root account. Still, foobar suggests that the use of sudo and temporary root logins for graphical administration tools provide a backdoor for gaining root access. According to foobar, all that a piece of malware would need to do is make a local copy of an administration tool, then run the malware referencing the local copy. A user would then enter the root password for the tool, and not notice that the malware command was also receiving root access. Alternatively, the malware could add a similar command to the path definition of the current account. Either way, foobar writes, "there's a good chance that you will get [root access] eventually if you are patient."

These suggestions are not new. LWN pointed out the basic problem nearly three years ago, and the potential vulnerabilities of sudo were pointed out two years ago in an Ubuntu forum. All the same, foobar's post has been widely discussed since it first appeared. Besides the comments below the post, it has been discussed in such places as Linux Today, LWN, Slashdot, the KDE Community Forums, and the Ubuntu Forums.

Much of this discussion is repetitive, and beside the point. For example, some users quibble that foobar is technically referring to a trojan, not a virus at all. Others, like "Felice" below the original post, dismiss foobar's analysis on the grounds that, "There will never be any protection against the user's stupidity." Others, like "friends of the one law" (also beneath the original post) insists that such exploits are less likely on GNU/Linux than on Windows because "The installation and/or maintenance of a basic linux desktop requires a level of knowledge _and_ intellect somewhat more developed than that required for a basic Micro$oft product." All these comments, however, are side issues that do not alter the basic problem in any way, even though they each contain some degree of truth.

Other comments were more to the point. Expanding on a comment by foobar, "Colin" posted beneath the original post with a link to the code snippet that prevents Thunar, the Xfce file manager, from having the same desktop vulnerability. Still others tried to correct foobar's suggested code or variations on the basic method outlined.

Some of the most focused responses appeared as comments to LWN's initial coverage of the story. "drag" suggested using a tool like SELinux to create a security context for downloads to the desktop that flags them as untrusted until they are specifically marked as trusted. The same commenter suggested that downloads should be savable only to a designated directory off the desktop — although, as foobar pointed out in the followup blog post, whether this idea would work is uncertain.

In the last few days, both GNOME and KDE have been taking concrete steps to alleviate the problem, with discussions taking place on the XDG (Free Desktop) list. In a blog post, Michael Pyne proposes a policy that will allow files with a .desktop extension to run if they are owned by root (and therefore part of a standard installation), or installed from "a known location for services, applications, and XDG-compliant applications" (that is, ones that meet the shared Free Desktop standards). A whitelist will track all .desktop files that are permitted to run.

Pyne tells LWN that a major challenge of implementation is getting the white list correct. His first whitelist excluded autostart entries, and discussion raised a number of other cases, such as whether existing .desktop files needed to be updated, and how to handle launchers created from a menu or panel.

Another issue raised on the XDG list is whether a header should be added to untrusted .desktop files to prevent them from being run from the command line. While some developers questioned the need, Pyne seems to have decided that the precaution is necessary.

Still another concern is to write a clear dialog window that opens when a user tries to launch a .desktop file that is not whitelisted and is therefore not executable. The language is still being improved, but will probably explain the potential danger and when you should and should not continue to run the program, as well as giving the complete path to the command.

GNOME developer Alexander Larsson, although writing that the issue is "all pretty overblown," is working along similar lines. When the changes are implemented, GNOME will add an executable permission to all existing .desktop files when upgrading — a move that KDE, for now, will not follow. "We thought about it but opted to start with the dialog," Pyne tells LWN. "Some kind of dialog will be required no matter what, and any auto-upgrade we do in KDE would have to be done with the user's permission. We may still do it, but it not set yet."

Another difference in GNOME is that any .desktop files that are executable but not in a system directory will be flagged as "untrusted." To emphasize their status, such files will show a shortcut icon and the real file name, rather than any custom icon and display name for the desktop. Pyne has expressed some interest in this idea to LWN, and briefly speculated about how files might be listed as trusted, but, for now KDE is not following this suggestion.

However, much as in KDE, clicking an untrusted file in GNOME will open a dialog that warns the user about the file's status, and gives the choice of running it anyway, marking it as trusted, or canceling its execution.

In both GNOME and KDE, these changes should appear very shortly. Larsson asked for a string break approval for next month's release of GNOME 2.26 so that his changes, particularly the new dialog, can be included. The request was granted, and Larsson tells LWN, "all the required Gnome changes have now landed in glib and nautilus."

Similarly, Pyne hopes to see his changes backported to KDE 4.2 in a point release, as well as appearing in KDE 4.3. Whether the backports occur, he explains to LWN, depends "on if it's deemed a big enough security risk."

The speed with which these changes are being implemented suggests that both KDE and GNOME are treating the security problem as moderately serious. However, Pyne is careful to warn about the limits of the fixes, telling LWN:

In other words, the fixes should minimize the chances of a malware infection of the type describes by foobar, but, as many commenters have pointed out, nothing can completely counter user ignorance, rashness, or plain stupidity. The most that desktop developers can do, short of restricting desktop files to a degree that most users would find unacceptable, is to make users aware of the consequences of their possible actions.

Comments (33 posted)

OpenSSH 5.2 released

Full Story (comments: none)

The Cryptography Olympics : the hash algorithm contest (The H)

Comments (none posted)

epiphany: arbitrary code execution

Comments (none posted)

git: arbitrary code execution

Comments (none posted)

kernel: various issues

Comments (none posted)

libpng: arbitrary code execution

Comments (none posted)

perl-Crypt-OpenSSL-DSA: improper error check

Comments (none posted)

php: remote file inclusion vulerability

Comments (none posted)

php: arbitrary file overwrite

Comments (none posted)

pycrypto: arbitrary code execution

Comments (none posted)

trickle: local code execution

Comments (none posted)

vim: arbitrary code execution

Comments (none posted)