Re: Tracker as a security risks

Hey Philip :),

On Mon, Dec 5, 2016 at 6:28 PM, Philip Withnall <philip tecnocode co uk> wrote:

On Mon, 2016-12-05 at 16:42 +0100, Carlos Garnacho wrote:
On Mon, Dec 5, 2016 at 3:01 PM, Hanno Böck <hanno hboeck de> wrote:
On Mon, 5 Dec 2016 13:44:40 +0000
Sam Thursfield <ssssam gmail com> wrote:

The design of Tracker takes the risks into account. Metadata
extraction is isolated in its own process (tracker-extract) which
crash without (theoretically) causing any harm.

I don't see how that helps against security vulnerabilities.

Having an isolated process probably helps in a way that a crash
cause the whole tracker service to malfunction. Thus parsing broken
files won't cause a service disruption. But as long as this process
runs with normal user rights this doesn't protect in a security

I think there needs to be a wider discussion about this and the
fundamental design choices done here need to be questioned.

What questions do you have in particular?

Quite frankly, I don't claim to have all the answers here, that's
why I
formulated it in an open "needs discussion" way.

I think sandboxing the tracker parser (which you already indicated
in your mail) is probably the most reasonable way to go forward.
isn't exactly my area of expertise, so I can't comment on which
technique here is most promising.

It indeed sounds possible to lift extraction into a separate process
with limited access to the filesystem, we essentially need to pass an
fd to mmap() and an output one to receive sparql back. There's just
two things to consider:

- The extraction process sometimes needs access to misc files (eg.
files, XMP sidecar files, ...), those might be passed along too, but
then we need detecting those cases beforehand.

- Ideally we wouldn't spawn one process per file being extracted,
although if we go to defcon 1 level of paranoia, that's probably what
should happen.

I would suggest a single sandboxed extraction process, which has read-
only access to the whole of ~/, and write access to the Tracker
database. No network access. That means that regardless of whether or

All changes to the database must be managed by a single thread, which
currently resides in tracker-store, update requests are received via
DBus. So we wouldn't need write access to the database, but we'd need
a connection to the tracker-store process, direct or indirect.

how the extraction process gets compromised, it cannot compromise the
integrity of any of the files in your home directory (except the
Tracker database, which I assume people aren’t too precious about), and
it can’t compromise the confidentiality of any of your data (except by
leaking it through the Tracker database — can we assume the database
format is sufficiently prescribed to be able to prevent this?).

Well... it isn't. If you have readonly/readwrite access to
~/.cache/tracker/meta.db, you have such access to all of it, if the
attacker can do sqlite3_open(), it will bypass any artificial security
restriction we may set (eg. Now,
readonly access to the database seems moot if all of ~/ is also
readonly, and with write access all you'd get is to tamper with the

Readonly access to ~/ kind of concerns me, although might not be used
for any ransomware after all if the targeted file can't be encrypted
nor sent over the network, there seems to be little to do with the
knowledge that might be gained if it can't get out of the process
except over the pipe feeding tracker-store.

This should be easily accomplished by using an AppArmor (or
equivalently, SELinux) profile for tracker-extract. seccomp-bpf could
also be used to achieve much the same thing, regardless of whether an
LSM is enabled.

The Apertis project has such an AppArmor file already, and it would be
great if that were pulled upstream:

(I am not claiming this profile is perfect, but it’s a start.)

Thanks for the tip :), worth a look indeed, although I'm looking into
using seccomp directly.

Anyway, this goes IMHO too much on the technical side for this ML, we
already have filed
to Tracker, and it's already high in my list for fixing on 1.12, feel
free to join there.

And I should add... Tracker is not alone here, if it's not Tracker
stumbling on infected content, with varying but still rather low
levels of interaction it may be a thumbnailer, a previewer like
or the web browser itself streaming content which hit this. So
more places in need of further isolation when dealing with untrusted

And still, the chain is only as strong as its weakest link, as soon
there is anything opening that file with wide enough permissions to
cause any harm, you're essentially screwed. This might sound like an
argument to running every app through flatpak, although I think the
long term answer always is "fix the vulnerability!".

Agreed. Thumbnailers are another big target here.

The other issue I think is that the quality of huge parts of the
ecosystem needs to be improved. The good news here is that we got
powerful tools in terms of fuzzing (afl, libfuzzer) and memory
bug detection (asan) in the past years. Ideally all free software
should be aware of those tools and use them in their development
process. I'm trying to help here where I can, see e.g. also my
post on this list [1]. If our libraries would be better tested we
be more comfortable feeding it with untrusted inputs.

I agree some more active prevention would be positive, sounds like
something to tackle in the libraries dealing with file formats
Tracker is a strawman here, in the sense that filesystem extraction
it's only exploitable through its tracker-extract's modules, and
are for the most part implemented using external libraries.

I think the point here is that Tracker will start extracting things
from files when they appear on the file system. So while a malicious
file could have caused problems eventually (when the user opens it),
the presence of Tracker means it can start causing problems a lot
earlier, without the user necessarily realising.

Sure, that absolutely needs fixing. My point was that other pieces of
the environment could benefit more directly about input fuzzing than
Tracker, as we don't usually implement the "parse the format" bits,
with just one exception.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]