Re: Tracker as a security risks

[Emilio Pozuelo Monfort <pochu27 gmail com>]

On 05/12/16 14:03, Hanno Böck wrote:
> Hi,
>
> I wanted to point out a recent blogpost by IT security export Chris
> Evans:
> https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html
>
> The short version: Chrome automatically downloads files without a file
> dialog, tracker (part of the GNOME desktop) subsequently automatically
> indexes these files with a wide variety of parsers (including
> gstreamer, but also others like imagemagick).
>
> While the bugs that evans points out have been fixed (and the gstreamer
> team has fixed a whole bunch of other potential security issues I
> reported in the past days, thanks!), the whole design of Tracker seems
> incredibly risky. It is certainly worthwhile trying to make the
> underlying software more secure, but having tried to do that before
> I find it unlikely that projects like gstreamer or imagemagick will
> ever be in a state where we can feel comfortable feeding them with
> untrusted files.
>
> The core problem here is that tracker automatically parses files of
> potentially unknown origin with parsers that haven't been built with
> security in mind. This happens without any sandboxing.
>
> I think there needs to be a wider discussion about this and the
> fundamental design choices done here need to be questioned.

Thanks for starting this discussion.

I think these questions also apply to the thumbnailer service and to
gtk+/gdk-pixbuf APIs, e.g. the filechooser. See e.g.
http://www.openwall.com/lists/oss-security/2016/07/13/11 aka CVE-2016-6352,
and http://seclists.org/oss-sec/2016/q3/7 aka CVE-2016-6163.

Cheers,
Emilio