Coordinated Disclosure: 1-Click RCE on Gnome (CVE-2023-43641) | Hacker News Reader

Coordinated Disclosure: 1-Click RCE on Gnome (CVE-2023-43641)

github.blog

78 pointsugjka20 comments

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.

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

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.

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

The really surprising thing is that GNOME has an official component called "tracker-miners". It's like they're deliberately trying to make it sound malicious. How much unnecessary stress has this name caused to people who thought it was some kind of keylogger or cryptominer malware?

Looks like that project was named in 2005, well before the widespread understanding of tracking cookies or cryptomining.

As the other commenter mentioned, it predates those being malicious sounding. That said, it definitely scared me when I first saw it in my ps list.

> The offsets in the full PoC need to be tuned for different distributions.

I remember an old joke about linux not having viruses because it is hard to guarantee it could run reliably on different distros. Well... that is not too far from reality actually.

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

… and then we check that `i` is positive, instead of using the proper type of size_t, which avoids the entire problem of negative indexes from the get go. (Though size_t doesn't save you from having to write a decent parser…)

The post also notes how the code fails to check for failures during parsing while calling atoi (mainly because atoi is one of those garbage-tier functions in C's stdlib that you should never call, in this case because it is incapable of signalling errors) … but then does nothing about it. So even after this patch, atoi can still return random garbage and in some cases the parser will just happily keep on using that. (But it shouldn't access random memory, I suppose.)

I think I finally managed to disable tracker-miner on xfce.

  systemctl --user list-unit-files | grep -o "tracker-\S*\.service" | xargs systemctl --user mask

...wasn't enough. What did the trick was unchecking the remaining two entries in the "session and startup" settings dialog. Good riddance. It was the number one reason for my notebook heating up and draining battery.

To patch a Fedora 38 system, use the command:

> sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-eec9ce5935

a quick fix would be to either uninstall libcue (on my machine only tracker-miners and gnome-photos depended on it) or configure tracker-miners to not scan cue files:

https://askubuntu.com/questions/1012772/how-do-you-configure...

consequently i used dconf to add '*.cue' to org > freedesktop > Tracker > Miner > Files > Ignored files

can anyone confirm that this would be sufficient?

libcue 2.3.0 contains the patch. The security advisory rates this as Medium (https://github.com/lipnitsk/libcue/security/advisories/GHSA-...).

Reply on news.ycombinator.com