.desktop file security

As most of you may have seen by now, foobar had made a post 10 days ago called “How to write a Linux virus in 5 easy steps.” That blog post was later covered on Slashdot and LWN, and describes the lack of security around .desktop launcher files. These .desktop files do lots of things, but one of their most prominent uses is in program launching.

Why are they needed? Well, they give a lot of extra metadata to executable programs, such as the icon to show, the friendly name, i18n translations, program working directory, whether a terminal-viewer should be launched in association, etc. Ever since their introduction, a .desktop file has been able to complete launching its associated program without being executable (that is, without have the +x bit set on the file for POSIX systems).

foobar makes a good point that in such a situation .desktop files are hardly any different than .vbs files in their effect if they were to be transported over email, and even if a .desktop file extension is not used, if the file “looks like” a .desktop file it will be handled as such. (For instance, on my KDE trunk desktop a .desktop file will be found out with a different extension or no extension, unless the fake extension is a known mimetype (like .jpg -> image/jpeg))

So this past week after some prompting by John Tapsell reminding us that we can’t drop the ball again I’ve been working on making .desktop files more secure. The issue is that we can’t simply require +x and see what happens, as even the installed menu icons in Kickoff are .desktop files, not to mention shortcuts on the Desktop and in the panel.

The alternative we hit upon in kde-core-devel was to allow .desktop file execution in the following cases:

  • If the .desktop file were owned by root (i.e. part of a standard system installation)
  • If the .desktop file was installed as part of the desktop environment (that is, it is from a known location for services, applications, and XDG-compliant applications. These correspond to the “services”, “apps”, and “xdgdata-apps” parameters to kde4-config --install). This allows for KDE installations to $HOME for instance.
  • Finally, having the file be executable by the user always allows the launcher to run.

Unfortunately this still leaves the problem of what to do with launchers on the desktop or in the panel. Going forward we will need to make such .desktop files executable when they’re created but users who are upgrading would all of a sudden lose their custom launchers if that was all we did.

So in addition to the lockdown code I’ve been working on a reliable means of giving the user the option of automatically “fixing” the .desktop file and continuing on with execution. Doing this would make the file executable, and add an appropriate #! header if one wasn’t already present. (The interpreter used for .desktop files is /usr/bin/env xdg-open).

This is an example of a dialog that would pop up for such a file (“mileage tracker.desktop”):

Dialog security popup example for launchers

The text isn’t set in stone yet (i.e. please suggest something better ;), I’m trying to make it descriptive enough to be useful without making the text so long as to simply lull the user into clicking “continue”.

One thing I haven’t done yet is to touch base with the XDG mailing lists to see if this requires revision to the specification (that way we don’t unintentionally break GNOME/Xfce/etc. apps on KDE, and don’t have ours broken). Mostly this was a matter of time — I already have little of it so it hasn’t quite percolated up in my priority list yet.

You can see my latest patches on the kde-core-devel mailing list. If you see any issues please don’t hesitate to email me or otherwise let me know sooner rather than later so we can either get them fixed or verify that it’s not an issue.

21 thoughts on “.desktop file security

  1. Arthur Pemberton Identicon Arthur Pemberton

    I understand your wish to help upgraders. But please do not including this ‘autofix’ for more than one release. Have one release with this so upgraders get through easily, then axe it before it comes just another dialog to click ‘Okay’ on.

    Also, I know *nix doesn’t need extensions, but you may want to consider only treating *.desktop as desktop files. With consistency, this would give email clients the option of warning/banning .desktop attachments period.

  2. Duane Identicon Duane

    I like Arthur’s idea of only treating a file with the .desktop extension as a .desktop file. That would create one less possible area of attack.

    Thank you for taking the time to work on these issues. While not something that causes problems currently, it will be a big help to not cause problems later.

  3. Leon Bottou Identicon Leon Bottou

    The second case (desktop files in the “services”,
    “apps”, and “xdgdata-apps” parameters to kde4-config –install)
    is dangerous when the file is owned by the user.
    It is too easy to trick the user to save a malicious
    desktop file into these directories.

    It would be better to fix kde to make sure that these desktop
    files as executable in the first place. That involves including an upgrade script that fixes those left by the user before the
    change. The dialog box would take care of the rest…

  4. derram Identicon derram

    I say add a third button along the lines of “Examine Code”, which then opens the file in a text editor.

  5. Thiago Macieira Identicon Thiago Macieira

    I don’t think it’s necessary to Examine Code, but the dialog can show the command that would be executed. After all, it’s just reading the desktop file and processing the Exec line. (and expanding Exec[$e] if necessary)

    That way, you can judge whether it’s malicious or not by seeing what would be run. If it’s the name of a well-known program, it’s probably not malicious. If it’s a long obscure, command, it probably is.

    The dialog then has to be extra careful about whether the .desktop file can trick it into showing something different from what would be executed.

  6. Fri13 Identicon Fri13

    I would first start to suggest drop off the “Continue” “Cancel” situation.

    We are talking (again) about warning dialog, what pop-ups and normal users does not like these at all. They just want to get things done and continue what they were doing. They usually do not read the message but they just click “Ok” “Continue” etc to get pass of it.

    So, change the buttons like “This is a Secure” and “This is Not a Secure” what is the answer for the text. Then alarm bells rises easier even for normal users heads and they think “Secure or not secure how? What is this?” And do not use the icons on the buttons, that is one hint for the user too, if there is green “OK” and red “STOP” icons on buttons, people do not always read the text but clicks just the green. This is more like same kind stupid action what normal users does.

    The text can be this kind long, but it should in first time at least, demand that user understand the situation where the question is asked. Same level we can teach them that these dialogs ain’t about “Do you want to continue or stop” but “Is this secure or not?”

    The Windows Vista’s UAC problem was it popped all the time in first versions. And the same problem is all over other applications too giving warnings with answers like “Continue” “Cancel”. That is just stupid, because the dialog assumes that user already has read the text and is thinking it. Same problem has systems what use the sudo to replace root. You can already find that too many Ubuntu users (because Ubuntu was one of first who violated the Sudo purpose!) gives their _own_ password to do something. For security reasons, there should always be different passwords for users and for system maintenance and currently Ubuntu is terrible in security because it teach wrong habits what just ends up to same as Vista, that people click “Allow” (sudo ) without understanding what they are doing, should it be done as root/admin rights or not. Thats why Canonical should start using more secure root/user accounts than trying to replace root with sudo and same time teaching unsecure habits for it’s users. (there is no reasons why sudo would be more secure than root account activated because you can not connect to root account from remote, only from localhost if configured well, and everyone knows that most unsecure piece on the chain is the user itself. Sudo is just used on Ubuntu to give easier use, not better security!).

    I have noticed this even myself that everytime I configure the KMail, and I have done that multiple times! There pop-ups somewhere the warning dialog without “OK” and “Cancel” buttons and icons on them, even the user who does that a lot, stops and reads the warning what it is about.

    Just changing the button names and removing icons, is more like changing the “question -> answer” to “answer -> question” position. It is not important to know the answer, but the question. Just like on those TV-games where you get answer but you need to know the question to win. Like “Rome” and the answer for that is “What is the capital of Italy?”. So if you give the answer but you demand the question, you get people to think what is the purpose of this.

  7. asd Identicon asd

    You could also give an option to see the content of the file [more info option?].
    (with nepomuk it would also be nice to see its origin)

    The text is to long and dense… try something like this (bullet points)

    Press “Make as executable”, if:
    – if you created this service

    Press “Cancel”, if:
    – unsure …

    Just to make it clearer visually.

    Probably you could also suggest “try it in a guest user account”?

  8. maninalift Identicon maninalift

    I agree with a lot of the points above

    (1) I’m not sure I entirely understand the “known services” thing but it doesn’t seem secure to me.

    (2) users don’t like to think but in this case the really need to, the dialogue should force them to think before they click, along the lines of Fri13 OR

    (3) I agree also that the automatic change to executable dialogue should be temporary if at all possible.

  9. Karellen Identicon Karellen

    -1 to UAC-style dialog box. Users do not read dialog boxes.[0] They’ll click one button or the other. If nothing happens, they’ll try to do the thing they were trying to do before, and when the dialog pops up again, they’ll click the other button.

    +1 to files owned by root being OK. If an attacker can mess with them, you’re screwed anyway.

    -1 to files in known, but user-controlled, locations for the reason Leon points out. Just have “kde4-config –install” set them executable on install.

    +1 to a script that runs through your home directory and makes desktop files executable on upgrade. But … if this were to go in to 4.3, you’d still need it in 4.4 for people upgrading from 4.2 -> 4.4, such as for people who use their distro’s kde, and the distro jumps from any pre-4.3 to any post-4.3 release. But you’ll need to make sure you only run it once.

    +1 to communicating with xdg/Gnome/etc… people to co-ordinate this. I’d suggest getting their input on the script, and thrashing out a single xdg .desktop upgrade script that all desktops can agree on. If you can also agree on a single xdg configuration option/file to say “desktop files executable”, then all you do is look for that config on login. If it’s set, do nothing. If it’s not set, run the update script to make them all executable, and then set the option.


    [0] http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

  10. bobp Identicon bobp

    I’m glad you’ve highlighted this issue and that you are looking at how to resolve it but I strongly disagree that this kind of dialog box is a good idea. Main reasons:

    1) Users do not read dialogs. Even giving the buttons more descriptive names will not fix this. Users do not have a good understanding of viruses, how computers become infected, how to protect themselves etc.

    2) Because of the above, if a user is unwise enough to click on a .desktop email attachment, they are highly likely to just say “yes” to any prompts. This would then become a major vector of attack for Linux. The old download/chmod step is enough to deter the inexperienced from this however.

    I think a much wiser solution is just to run an automatic fixing script (that is coupled with a kde upgrade for instance) that does chmod+x on all the usual locations for .desktop files (e.g. start menu) and just tell the user they’ll they to chmod+x future files . I don’t know how likely breakage would be but my feeling is the vast majority of users run .desktop files that are installed system wide and execute system wide applications.

    Please, learn from the mistakes in Windows 1) avoid dialogs like this and 2) don’t make it easier to run potential viruses.

  11. TheBlackCat Identicon TheBlackCat

    Would a more long-term solution be to require that the .desktop files themselves have executable permissions before they will be allowed to run, at least if they are not owned by root? I know this would require breaking some things now, but I think it would be better to break it now when Linux users tend to be, on average, more computer-savvy and the user base is smaller rather than find out we have a serious problem down the road and have to break it then for a large number of ordinary users who don’t have a clue what’s going on (like UAC)? .

  12. Nathan Identicon Nathan

    The UAC style box would only be coming up in a pretty limited set of circumstances, ie when a user has done some customization of launchers and after an upgrade that enforced the new +x rules and only once for each launcher if the user decides to trust it, so i think the potential is that a few power-ish user may see the dialogue up 5 or 10 times in their life. Not exactly over burdensome or the MS-UAC-Click through hell that is vista. The only other case is when there actually is an attempted attack in progress, and that seems like something the user should know about.

  13. mpyne Identicon mpyne Post author

    Whoa, lots of comments while I was away. Let me just go through some of the points I saw raised:

    – I am just as opposed to dialogs as the rest of you, trust me. I’d be much happier simply picking “the right thing” to do in code and having it done, as then I wouldn’t be having to write user-visible text. The problem is that there really are two valid choices here, the user thought they were running a program (i.e. desktop shortcut), or that the user had no idea they were running a program (i.e. OPEN THIS EMAIL!!). One the user chooses to run, the .desktop file is “fixed” and they’ll never receive the prompt again. If the user chooses to Cancel I can’t simply “neuter” the file to remove the dialog because the user may have just then decided that they know it’s a program but they didn’t feel like running it.

    – Thiago recommended adding a description of what’s being executed. I actually have added “details text” with that so KMessageBox is supposed to create a Details >> button with it, but that doesn’t happen. I’m still looking into it, but I agree we should do that too.

    – I like asd’s “bullet format”, I may re-do it that way even at the expense of space.

    – Lots of people have suggested upgrade scripts so that we don’t have to allow situations where we launch a desktop file without +x permission. I suggested that too at first, but unless you spend the amount of time to search all of $HOME you may miss some scripts in use and more dangerously, what if the user has already downloaded a trojan to their Desktop? Adding +x would be incredibly hurtful in that situation. And if you do search all of $HOME, that would take forever to complete.

    – People are wary of allowing “known services” to run but the fact of the matter is that the three locations checked contain actual programs by definition. For the vast majority of people this rule won’t matter since the “known service” will be owned by root and therefore already have an exception. This exception is to allow for KDE installations by single user or shared with a non-root owner. The alternative is that all of your commands in the kickoff or old-style K menu, and most of the commands accessible via KRunner stop working or require that nasty UAC-style prompt.

    Another thing to keep in mind is that once you’re assuming that the user can be fooled into saving a file deep into say, $HOME/kde-4/share/applications/kde4, you may as well assume that the user can be easily fooled into right clicking that desktop file and checking the “Is executable” checkbox. Allowing only executable files to run is a safety measure to avoid the user accidentally run a program when they were trying to open a file in a editor to see what it was, or to avoid running a attachment they happened to save to their desktop.

    Once you start assuming that the user will start following instructions from the attacker as well, they are already 0wned. ;)

    New .desktop file creations and new KDE installations will have executable .desktop files where necessary, the prompt is to allow for users to have a chance at using their old shortcuts without too much pain, and will only show up once for each shortcut. By the time 4.4 rolls around a user should probably never have to see the dialog again (at which time perhaps we’ll remove it and make users click that check box themselves) ;)

  14. TheBlackCat Identicon TheBlackCat

    When the user first uses KDE, after a random period of time between 2 hours and 24, the user should get the following message:

    If you pay attention to warning messages, hold ctrl+meta+r and hit Home three times. Do not press either of the buttons below

    OK Cancel

    And if the user presses either of the buttons then KDE knows they are dealing with someone who doesn’t pay attention and changes the system appropriately.

    Yeah, it isn’t actually a very good idea but it would be pretty funny to see.

  15. Pingback: Virus para (GNOME/KDE)+Linux - BLOG Eduardo Escobar

  16. bobp Identicon bobp

    I do not agree about the right-click/properties/chmod+x comment that users would just do this if the OK dialog wasnt there. The properties box is a bothersome enough action to have to perform that it discourages you from just running any old thing you click on. When you click something and expect it to run, clicking “OK” is just something people tend to automatically do without thinking. Going into the properties menu takes some thought, the options look a bit scary, you’re having to think more about what you’re doing.

    I don’t think I’ve ever seen any linux software offer to chmod+x things and its for a very good reason. You’re better off with the rare occurance of users not being able to run some shortcuts (this is going to be very rare as only powerusers are going to be playing with custom .desktop files) than opening up a huge attack vector that plagues Windows.

    Seriously, you really need to consider this more IMO. Having some bullet points and some nicely worded buttons is not going to discourage people who click on random email attachments. Having to save/right-click/click a tab/click a specific checkbox etc. requires some knowledge and perseverance which is good at stopping naive users.

  17. Pingback: » Virus para (GNOME/KDE)+Linux | Computadora Z3 | La primera máquina programable y completamente automática !!!

  18. Afief Halumi Identicon Afief Halumi

    Maybe I’m just uninformed, but could someone tell me what’s wrong with requiring the .desktop files to be executable? as far as I am concerned most of the functionality of .desktop files can be replaced with a python script(overkill, but just for the sake of example) and I’d be damned if I didn’t require that one to be executable.

    Sorry if I’m asking a stupid question but I’d really like to understand.


  19. Karellen Identicon Karellen

    @Afief Halumi

    The problem is that at the moment they are not required to be executable. So people have existing .desktop files that are not executable which currently work.

    If you suddenly require that they are executable, you will break people’s existing environments. This is bad.

  20. Gonzalo Porcel Identicon Gonzalo Porcel

    Better and shorter warning:

    This icon is not marked as an executable program.

    If you created this shortcut, click “Make Service Executable
    and Continue”. Otherwise, click “Cancel” as it is likely
    a malicious program.

  21. sir Identicon sir

    What about some information?

    You’re going to run “xy” application with exec command “zy”

Comments are closed.