Tails

#2 Updated by Anonymous 2016-11-21 14:44:33

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

#3 Updated by intrigeri 2016-11-22 07:42:11

> 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 2016-11-24 07:59:08

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 2016-11-25 10:34:08

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 2016-11-25 11:25:13

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 2016-11-25 11:44:44

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 2016-11-25 11:58:38

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 2016-11-27 16:48:54

> 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 2016-11-29 07:55:28

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 2016-12-06 10:22:06

> 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 2016-12-06 10:22:39

> 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 2016-12-09 10:00:09

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 2016-12-10 07:58:53

> 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.

#18 Updated by cypherpunks 2017-03-04 00:47:04

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 2017-03-04 01:13:08

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 2017-03-20 13:58:25

> 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 2017-03-20 14:09:49

> 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.)

#23 Updated by intrigeri 2017-07-22 06:10:03

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 Feature #12615) whatever work is done on this ticket will be essentially useless. So IMO it’s a matter of timing: if we decide on Feature #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.

#25 Updated by Anonymous 2018-08-17 14:57:23

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