Linux Desktop Security Vulnerabilities
A common method for infection of many operating systems is a malicious executable file–either sent in an email or downloaded otherwise–that the user simply double clicks without thinking. Because most users are so used to the concept of double click to open
they may not in fact realize that they could be executing arbitrary code (especially with a default setting to hide file extensions) or that arbitrary code even running with low permissions, can still be incredibly dangerous.
A big selling point of security on many Linux or Unix systems is the distinction of Execute permissions. A downloaded file will not have the execute bit set. This means that, within a window manager, double-clicking will only attempt to read the file so the desktop system may ask what you want to do with it. Only by either explicitly telling this prompt to execute or by editing the permissions of the file from the command line can you execute this file. In either case this is an explicit action that the user must think about.
However, many distributions of Linux use a standardized .desktop [1] file format. These files are often used as menu items or program launcher shortcuts: they have an Exec parameter that can take an arbitrary command string to run when clicked.
[Desktop Entry] Encoding=UTF-8 Type=Application Terminal=false Exec=bash -c "touch ~/haxxored" Name=Write to an arbitrary file.
A desktop file that creates the file haxxored
in the user’s home directory
Users and developers of these distributions have recently been arguing for re-evaluation of this specification for that very reason: they allow arbitrary code execution without the need for an executable bit set on the file.
This opens up the same vulnerability in Linux systems that had previously been avoided. An inexperienced user used to double click to open
might download a .desktop file and try to open it. Even a more experienced user might not realize this issue and (expecting the previously mentioned behavior of simply reading the contents of the file) click on it to see the contents.
Even more troubling is the behavior of these Desktop files when used in the menuing system for many distributions: important system applications often have menu entries in /usr/share/applications. However, menu entries with the same name in ~/.local/share (the user’s local directory) with the same Name option will override the system one! A malicious script (perhaps even started by the exploit above) could shadow the desktop entry from one of the important system applications such as the Synaptic Package Manager. Users are used to typing their passwords at the gksu prompt when clicking on Synaptic so they would do so; now a malicious script has root access to the user’s machine.
Possible Solution
The biggest part of a solution to this problem would be requiring that .desktop files simply have execute permission set. On installation of a normal program this would be a trivial addition, but downloaded .desktop files would not be run. In case of some other malicious script gaining user access, normal users should not be able to override root owned .desktop files (like Synaptic).
These solutions are extremely simple, but they have not been implemented yet due to the desire for compatibility between
different distributions. It may take time for these changes to be made.
[1] Desktop File Specification: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html