5 ms·

This kind of bug isn't supposed to be exploitable because the extract process is sandboxed. The real vulnerability of concern IMO is that the sandbox was so ea

This kind of bug isn't supposed to be exploitable because the extract process is sandboxed. The real vulnerability of concern IMO is that the sandbox was so easily escaped. 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. The only thing making this architecture remotely sane is the sandboxing. It's rather concerning that was so easily bypassed TFA hadn't even realized they were escaping a sandbox.

Aeolos 3y ago
> 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...
- dtx1 3y ago
  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
- Zee38484 3y ago
  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.
  - fs111 3y ago
    > It is also easy to run browser in well protected virtual machine sandbox. Yeah, so easy that literally nobody does this.
tannhaeuser 3y ago
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/f0c880a0ec0e650dbdc037c59e58e07442f82fef https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/f0c88...
- josephcsible 3y ago
  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.
deleted 3y ago
[deleted]
blueflow 3y ago
> 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".
formerly_proven 3y ago
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.
- naranha 3y ago
  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.
rollcat 3y ago
> 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 https://man7.org/linux/man-pages/man2/seccomp.2.html> vs <http://man.openbsd.org/pledge.2 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.

Aeolos 3y ago

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

dtx1 3y ago
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
Zee38484 3y ago
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.
- fs111 3y ago
  > It is also easy to run browser in well protected virtual machine sandbox. Yeah, so easy that literally nobody does this.

tannhaeuser 3y ago

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/f0c880a0ec0e650dbdc037c59e58e07442f82fef https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/f0c88...

josephcsible 3y ago
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.

deleted 3y ago

[deleted]

blueflow 3y ago

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

formerly_proven 3y ago

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.

naranha 3y ago
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.

rollcat 3y ago

> 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 https://man7.org/linux/man-pages/man2/seccomp.2.html> vs <http://man.openbsd.org/pledge.2 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.