Project

General

Profile

Feature #11881

Disable preview in Nautilus by default to prevent potential execution of malicious data

Added by Anonymous over 2 years ago. Updated 9 months ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
10/20/2016
Due date:
% Done:

0%

QA Check:
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

no text


Related issues

Related to Tails - Feature #12615: Consider basing Tails on quarterly snapshots of Debian testing In Progress 06/13/2017

History

#1 Updated by elouann over 2 years ago

  • QA Check set to Info Needed

Could you please clarify which problem this would solve?
Thank you

#2 Updated by u over 2 years ago

Is there any CVE against Nautilus which you are maybe referring to?

#3 Updated by intrigeri over 2 years ago

Is there any CVE against Nautilus which you are maybe referring to?

I suspect that the various tools & libraries that Nautilus uses for creating previews have more chances to have security issues than Nautilus itself.

#4 Updated by cypherpunks over 2 years ago

intrigeri wrote:

Is there any CVE against Nautilus which you are maybe referring to?

I suspect that the various tools & libraries that Nautilus uses for creating previews have more chances to have security issues than Nautilus itself.

I think that's what he's talking about. The previews are generated by the tools/libraries after all. Nautilus itself would be unlikely to have such vulnerabilities, because it probably uses libpng, libjpeg, libav, libxml, etc. for preview generation.

I'm sure a lot of people would be annoyed if all previews were disabled. A compromise might be to whitelist preview formats, so only specific file types have previews generated for them, if that's possible. For example, the official libraries for the jpeg2000 and tiff formats (openjpeg and libtiff, respectively) both very recently had severe arbitrary code execution vulnerabilities. Neither of those formats are in wide use. If they were disabled from automatic preview generation, it would affect extremely few people, and would completely prevent such automatic code execution through simply viewing a directory in nautilus. And of course, there are dozens and dozens of other even less safe and less well audited formats out there (especially video formats) which are guaranteed to have quite trivial code execution vulnerabilities, yet which people will effectively never legitimately come across. Limiting the attack surface area to mpeg/mpeg4, h.264, vp8/vp9, and divx for video, and jpeg, png, and gif for images would greatly decrease the likelihood of an exploit in, say, svg or xml or realvideo.

#5 Updated by cypherpunks over 2 years ago

https://scarybeastsecurity.blogspot.nl/2016/11/0day-exploit-compromising-linux-desktop.html

An example of Nautilus preview triggering an exploit from a bug in gstreamer.

When the Downloads folder is later viewed in a file manager such as nautilus, an attempt is made to auto thumbnail files with known suffixes (so again, call the NSF exploit something.mp3). The exploit works against the thumbnailer.

Tails also installs gstreamer-plugins-bad which has questionable code quality and many obscure plugins.

#6 Updated by cypherpunks over 2 years ago

cypherpunks wrote:

https://scarybeastsecurity.blogspot.nl/2016/11/0day-exploit-compromising-linux-desktop.html

An example of Nautilus preview triggering an exploit from a bug in gstreamer.

When the Downloads folder is later viewed in a file manager such as nautilus, an attempt is made to auto thumbnail files with known suffixes (so again, call the NSF exploit something.mp3). The exploit works against the thumbnailer.

Tails also installs gstreamer-plugins-bad which has questionable code quality and many obscure plugins.

Even worse, it looks like it installs 0.10. According to a comment on that post:

Also, keep in mind that 0.10 is abandoned. Has been for years. 1.0 is its successor. I would consider using 0.10 these days a security vulnerability in itself. Switch to 1.0.

Frustratingly, it seems pidgin (along with tails-persistence-setup?) depends on 0.10, even though 1.0 is actually installed alongside 0.10... Which is frustrating, because it's the only actual package that would be removed if 0.10 were uninstalled.

#7 Updated by cypherpunks over 2 years ago

cypherpunks wrote:

Even worse, it looks like it installs 0.10.

I believe nautilus in Tails 2.7 only uses libraries from gstreamer 1.0. Tor Browser loads the 0.10 libraries when playing media, but I think firefox only uses gstreamer to play mp3's. (can be disabled in about:config media.gstreamer.enabled )

Chris Evans also found 2 more vulnerabilities in gstreamer that affect 1.0

https://scarybeastsecurity.blogspot.nl/2016/11/0day-exploit-advancing-exploitation.html

#8 Updated by cypherpunks over 2 years ago

cypherpunks wrote:

Chris Evans also found 2 more vulnerabilities in gstreamer that affect 1.0

https://scarybeastsecurity.blogspot.nl/2016/11/0day-exploit-advancing-exploitation.html

Yeah I noticed that. You know if those affect Tails currently? They didn't do anything when I tested them (even the generic crash PoC which should work on most systems regardless of glibc version), but that could also be that a 32 bit userland is so different that it doesn't even cause a crash.

#9 Updated by intrigeri over 2 years ago

I believe nautilus in Tails 2.7 only uses libraries from gstreamer 1.0. Tor Browser loads the 0.10 libraries when playing media, but I think firefox only uses gstreamer to play mp3's. (can be disabled in about:config media.gstreamer.enabled )

FWIW Tails 3.0~alpha1 doesn't include gstreamer 0.10 at all.

#10 Updated by cypherpunks over 2 years ago

intrigeri wrote:

FWIW Tails 3.0~alpha1 doesn't include gstreamer 0.10 at all.

That's good news.

Do you think Tails could consider blacklisting obscure formats in general? I tested the simple mitigation of removing the libraries for several of them. There were no ill effects, and gstreamer just stopped supporting them. I think the libraries are as simple as plugins, and if they are present, gstreamer will support the format. If blacklisting plugins in the form of deleting .so files for obscure formats isn't a simple solution for Tails, then I don't know what is.

#11 Updated by intrigeri over 2 years ago

Do you think Tails could consider blacklisting obscure formats in general?

I've not checked on Jessie, but on current sid there's a org.gnome.desktop.thumbnailers disable gsettings pref, whose doc reads "List of mime-types for which external thumbnailer programs will be disabled". So this seems to be doable technically. Next step for anyone wanting to push this forward: come up with such a list of mime-types, each of them with an explanation of why it's particularly dangerous and it's worth taking the UX hit of disabling previews for it.

#12 Updated by intrigeri over 2 years ago

Tails also installs gstreamer-plugins-bad which has questionable code quality and many obscure plugins.

Let's not mix up different topics on a single ticket: please file a dedicated ticket about it if you want to discuss that :)

#13 Updated by cypherpunks over 2 years ago

intrigeri wrote:

Do you think Tails could consider blacklisting obscure formats in general?

I've not checked on Jessie, but on current sid there's a org.gnome.desktop.thumbnailers disable gsettings pref, whose doc reads "List of mime-types for which external thumbnailer programs will be disabled". So this seems to be doable technically. Next step for anyone wanting to push this forward: come up with such a list of mime-types, each of them with an explanation of why it's particularly dangerous and it's worth taking the UX hit of disabling previews for it.

There are a huge amount of dangerous formats and only a handful of common and useful ones. Why not do a whitelist instead? If the preference only supports a blacklist, then we could come up with an explanation of why an individual format is safe, instead of the other way around, and then put the others in the blacklist.

I hope that "external thumbnailer programs" does not mean "anything other than totem-video-thumbnailer", which itself supports dozens of dangerous formats. If that were the case, then I don't think any external thumbnailer programs are used anyway.

#14 Updated by intrigeri over 2 years ago

Why not do a whitelist instead? If the preference only supports a blacklist, […]

It only supports a block list, indeed.

then we could come up with an explanation of why an individual format is safe, instead of the other way around, and then put the others in the blacklist.

This would work.

#15 Updated by mercedes508 over 2 years ago

  • Assignee set to elouann

#16 Updated by mercedes508 over 2 years ago

  • Assignee changed from elouann to emmapeel

#17 Updated by intrigeri about 2 years ago

  • Subject changed from disable preview in nautilus by default to prevent potential execution of malicious data to Disable preview in Nautilus by default to prevent potential execution of malicious data
  • Status changed from New to Confirmed
  • Assignee deleted (emmapeel)
  • QA Check deleted (Info Needed)
  • Type of work changed from Debian to Research

I'd like to put things in the context of the most likely user story we're talking about: if the user has bothered saving a malicious file an attacker sent them, and visits that directory in the Files manager, chances are they'll open that file. So, there are two cases:

  • if the viewer (for example EOG, Totem or Evince) uses the same library as Nautilus: then it makes little sense to disable the preview, as the user will be exploited anyway; if that's the case, IMO the usability/security balance does not lean towards disabling the preview;
  • if the viewer uses different libraries: then it makes sense to disable the preview in Nautilus, but only if we sandbox the viewer somehow (current best option in Tails: AppArmor; we do that for Evince and Totem already).

Next step is to answer these questions for every format whose previewer uses dangerous libraries.

#18 Updated by cypherpunks about 2 years ago

intrigeri wrote:

I'd like to put things in the context of the most likely user story we're talking about: if the user has bothered saving a malicious file an attacker sent them, and visits that directory in the Files manager, chances are they'll open that file. So, there are two cases:

  • if the viewer (for example EOG, Totem or Evince) uses the same library as Nautilus: then it makes little sense to disable the preview, as the user will be exploited anyway; if that's the case, IMO the usability/security balance does not lean towards disabling the preview;
  • if the viewer uses different libraries: then it makes sense to disable the preview in Nautilus, but only if we sandbox the viewer somehow (current best option in Tails: AppArmor; we do that for Evince and Totem already).

Next step is to answer these questions for every format whose previewer uses dangerous libraries.

Why do you assume they will be opening every file that is previewed? Isn't it not uncommon to extract archives with many media files? If someone opens one or two and doesn't like what they see or is bored, they just delete the whole directory. They won't open them all. This isn't hypothetical. It comes from anecdotes from people I know (some of whom use Tails).

I think, rather than disabling previews for dangerous formats, we should disable the dangerous formats in the first place. There is no reason we should be supporting emulated NES audio, for example. Disabling it is as simple as changing the permission of a single library. Each library is a module that corresponds to a format. If the module is gone or not executable, gstreamer will not support that module. They are opened dynamically at runtime with dlsym(), so there is no issue with being unable to load due to missing libraries.

Disabling the formats would prevent both the preview and the playback of the media file. The file would simply be unsupported.

#19 Updated by cypherpunks about 2 years ago

intrigeri wrote:

  • if the viewer uses different libraries: then it makes sense to disable the preview in Nautilus, but only if we sandbox the viewer somehow (current best option in Tails: AppArmor; we do that for Evince and Totem already).

Though I still think disabling either unsafe preview formats or formats in general is the best way to go, confining eog with AppArmor is still very important, considering how great its attack surface area is. Telling people they have to open local images in Tor Browser with the file:// URI just to have a modicum of security gets tiresome...

I wrote an AppArmor policy for eog already, but the ticket here was rejected and redirected upstream. The upstream post was ignored because they had moved to git. I planned to send a merge request there but lost interest.

https://labs.riseup.net/code/issues/11150
https://lists.ubuntu.com/archives/apparmor/2016-February/009376.html

#20 Updated by intrigeri about 2 years ago

Why do you assume they will be opening every file that is previewed? Isn't it not uncommon to extract archives with many media files? If someone opens one or two and doesn't like what they see or is bored, they just delete the whole directory.

Fair enough.

I think, rather than disabling previews for dangerous formats, we should disable the dangerous formats in the first place.

This certainly makes sense for some formats. So we're back to: someone needs to build a list of such formats, and the corresponding libraries.

#21 Updated by intrigeri about 2 years ago

I wrote an AppArmor policy for eog already, but the ticket here was rejected and redirected upstream. The upstream post was ignored because they had moved to git. I planned to send a merge request there but lost interest.

(This is off-topic on this ticket, so let's close this part of the discussion with: https://wiki.debian.org/AppArmor/Contribute/Upstream has been updated and now includes instructions to submit merge requests to the upstream apparmor-profiles Git repo.)

#22 Updated by u almost 2 years ago

  • Starter deleted (Yes)

#23 Updated by intrigeri almost 2 years ago

See http://www.hadess.net/2017/07/security-for-security-gods-sandboxing.html. tl;dr: "For GNOME 3.26 (and today in git master), the thumbnailer stall will be doubly bolted by a Bubblewrap sandbox and a seccomp blacklist". So once Tails is based on Buster (which could happen either early 2018, or mid-2019, depending on #12615) whatever work is done on this ticket will be essentially useless. So IMO it's a matter of timing: if we decide on #12615 to switch to Buster early, then I say we should reject this ticket; OTOH if we decide to remain based on Stretch for 2 years, then it might be worth disabling the thumbnailers that have the worst usefulness / security risk ratio.

#24 Updated by u over 1 year ago

  • Related to Feature #12615: Consider basing Tails on quarterly snapshots of Debian testing added

#25 Updated by u 9 months ago

I thought we decided to port to Buster. Which means we could reject this ticket?

#26 Updated by intrigeri 9 months ago

  • Priority changed from Normal to Low

I thought we decided to port to Buster.

We decided to try to port early (#12615) but we failed.

Which means we could reject this ticket?

Tails 3.x will still be around for almost a year, so I'd welcome a good patch.
And then let's reject once we're closer to releasing 4.0.

Also available in: Atom PDF