I've briefly examined the mentioned commit in response to the sandbox escape [1], and am way out of my comfort zone here, but I basically can't understand how setting seccomp policies can be effective in the presence of an exploitable buffer overflow (cf. max size check and mention of ASLR failure/compromise).

[1]: https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/f0c88...

Buffer overflows can result in remote code execution, but it'll be within the same process, and there's no way to turn seccomp back off.

> There's very likely piles of bugs in all the surface area of everything involved in extracting/scanning the files. It definitely doesn't end here with this libcue bug.

This is one of the things that really scares me, not just in Linux but in every operating system. Afaik, metadata scanning is one of the biggest zero-click attack vectors on iOS.

In Linux I try to execute as much as possible under a sandbox (firejail), hoping that this makes any difference, but deep inside I am terrified about the piles upon piles of ancient C code running from Gnome all the way down to the driver stack...

Edit - from the article:

"There are two parts to the problem. The first is that the scanner (cue_scanner.l, line 132) uses atoi to scan the integers: [...] atoi does not check for integer overflow, so it is easy to construct a negative index. [...]

The second part of the problem (and this is the actual vulnerability) is that track_set_index does not check that i ≥ 0"

I hate to be that guy, but maybe C should no longer be considered a valid option for parsing unknown input, aka the first line of defense...

Try Qubes OS. It's by design very resistant to bugs like this. Escaping a hypervisor is somewhat harder than just a Sandbox. Add to that most drive by attacks won't even attempt it. It's a bit like driving a tank on the Street though

It is easy not to install tracker, tumbler and all sorts of garbage like that. It is also easy to run browser in well protected virtual machine sandbox.

Firejail exposes you to bugs in kernel. Not much better than tracker.

> It is also easy to run browser in well protected virtual machine sandbox.

Yeah, so easy that literally nobody does this.

> The real vulnerability of concern IMO is that the sandbox was so easily escaped.

People lock down some syscalls and call it "sandbox", despite the fact that the untrusted code is still running directly on your cpu and has access to all remaining kernel interfaces. "sandbox" is a misnomer for this. It should be sth like "there is a fence over there".

Software like this is always going to be a massive security liability. It doesn't really matter if it's Windows Indexing Services (which has a plugin infrastructure for supporting arbitrary file formats, which is used by well-known secure software like Adobe Reader, other Office programs and also supports a variety of multimedia formats), Gnome's tracker-miner or KDE's Baloo indexer.

I guess it's fine as long as it isn't running in untrusted durectories. I'd take downloads out and documents in by default.

> The real vulnerability of concern IMO is that the sandbox was so easily escaped.

Linux lacks effective sandboxing.

It *does* have complex, comprehensive, powerful, and therefore hard-to-use sandboxing, which is the actual root of the problem here: if security is difficult to implement, it will often end up being ineffective.

Compare <https://man7.org/linux/man-pages/man2/seccomp.2.html> vs <http://man.openbsd.org/pledge.2>. The two mechanisms have roughly the same goals. The former requires writing a BPF program; the latter is a single function call.