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...
> 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.
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).
> 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.
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?
> 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.)
...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.
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:
[+] [-] pengaru|2 years ago|reply
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|2 years ago|reply
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...
[+] [-] rollcat|2 years ago|reply
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.
[+] [-] tannhaeuser|2 years ago|reply
[1]: https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/f0c88...
[+] [-] blueflow|2 years ago|reply
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|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] mrob|2 years ago|reply
[+] [-] kibwen|2 years ago|reply
[+] [-] christophilus|2 years ago|reply
[+] [-] marcodiego|2 years ago|reply
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.
[+] [-] deathanatos|2 years ago|reply
… 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.)
[+] [-] encypruon|2 years ago|reply
[+] [-] Kostic|2 years ago|reply
> sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-eec9ce5935
[+] [-] em-bee|2 years ago|reply
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?
[+] [-] hrpnk|2 years ago|reply