interpreting .desktop files can be exploited

Bug #1660742 reported by Daniel Fore on 2017-01-31
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released
Jeremy Wootten

Bug Description

Following this discussion:

The TL;DR is that you can write a .desktop file that pretends to be an image. When a user goes to open it with image viewer, it can exec a script. Bad times. I've attached an example.

It seems like Nautilus and Thunar each have some pretty complicated systems to try to get around this by checking the path before executing or showing warning dialogs, but IMO, the simplest solution would be to only "thumbnail" .desktop files and not change their names. It seems like adding complexity just moves the goalpost and introduces more points for failure, not really solving the root of the exploit.

Slingshot and Plank already interpret names of .desktop files, so I can't really think of a great reason we should do this in Files.

If we removed the renaming we could also drop the "interpret .desktop file" gsetting since it would just fall under the normal thumbnailing we do with other file types.

Related branches

Daniel Fore (danrabbit) wrote :
information type: Public → Public Security
Changed in pantheon-files:
milestone: none → juno-beta1
Neal Gompa (ngompa13) on 2017-01-31
tags: added: security

An important caveat of this is that Nautilus 3.22 automatically extracts zip files, while Pantheon Files does not. It doesn't eliminate concern here, but it does make the attack vector more direct and less likely to happen accidentally.

In Nautilus, a user just has to click a zip file, then click the auto-extracted "image". In Files, if a user clicks the zip, they get the Archive Manager which shows a contained .desktop file. The would have to right-click -> extract the zip to bypass that.

However, I am inclined to agree that a file manager probably doesn't need to also pretend to be an app launcher. This might affect some unique edge case workflows of users (especially those coming from OS X and the "Applications folder", so we should probably expect some push back or confusion if this is fixed.

All said, I think fixing this would be an improvement. :)

Changed in pantheon-files:
status: New → Confirmed
importance: Undecided → High
Daniel Fore (danrabbit) wrote :

Yeah, this exploit doesn't really require the whole archive part to still work though.

After talking to Jeremy it sounds like we're going to do two things:

1. Don't hide the file name. We'll display the real file name for .desktop files

2. We'll treat .desktop files as a text file and not launch them (currently we launch them no matter whether they are made executable or not)

I think we all agree that Files is not an app launcher so special casing .desktop files doesn't make a lot of sense. Especially since Files doesn't manage the desktop, there's not a clear case for Files to behave like an app launcher.

Marking this report as "Triaged" since we seem to all agree about how to move forward :)

Changed in pantheon-files:
status: Confirmed → Triaged
Changed in pantheon-files:
status: Triaged → In Progress
assignee: nobody → Jeremy Wootten (jeremywootten)
Daniel Fore (danrabbit) on 2017-02-02
Changed in pantheon-files:
status: In Progress → Fix Committed
Cody Garver (codygarver) on 2017-02-26
Changed in pantheon-files:
milestone: juno-beta1 → 0.3.2
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Bug attachments