[HN Gopher] Coordinated Disclosure: 1-Click RCE on Gnome (CVE-20...
___________________________________________________________________
Coordinated Disclosure: 1-Click RCE on Gnome (CVE-2023-43641)
Author : ugjka
Score : 67 points
Date : 2023-10-11 08:10 UTC (7 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| mrob wrote:
| 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?
| kibwen wrote:
| Looks like that project was named in 2005, well before the
| widespread understanding of tracking cookies or cryptomining.
| christophilus wrote:
| 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.
| pengaru wrote:
| 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.
| tannhaeuser wrote:
| 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...
| [deleted]
| blueflow wrote:
| > 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".
| rollcat wrote:
| > 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.
| formerly_proven wrote:
| 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 wrote:
| 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.
| Aeolos wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > It is also easy to run browser in well protected virtual
| machine sandbox.
|
| Yeah, so easy that literally nobody does this.
| encypruon wrote:
| 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.
| Kostic wrote:
| To patch a Fedora 38 system, use the command:
|
| > sudo dnf upgrade --enablerepo=updates-testing --refresh
| --advisory=FEDORA-2023-eec9ce5935
| hrpnk wrote:
| libcue 2.3.0 contains the patch. The security advisory rates this
| as Medium (https://github.com/lipnitsk/libcue/security/advisories
| /GHSA-...).
| deathanatos wrote:
| > _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.)
| marcodiego wrote:
| > 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.
| em-bee wrote:
| 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?
___________________________________________________________________
(page generated 2023-10-11 16:02 UTC)