A remote code execution vulnerability in GNOME [LWN.net]

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:16 UTC (Tue) by rahulsundaram (subscriber, #21946)
In reply to: A remote code execution vulnerability in GNOME by madscientist
Parent article: A remote code execution vulnerability in GNOME

> According to the comments at the end of the linked article, the parser IS run in a sandbox. Unfortunately there was an issue with that (unpublished as of yet) that was since fixed as well (according to the article).

Details of the sandbox changes itself is covered in https://blogs.gnome.org/carlosg/2023/10/10/on-cve-2023-43...

to post comments

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 0:52 UTC (Wed) by roc (subscriber, #30627) [Link] (4 responses)

Having the main thread be fully privileged and running in the *same address space* as "sandboxed" threads is ridiculous and does not deserve to be called a sandbox at all.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 13:10 UTC (Wed) by fredrik (subscriber, #232) [Link] (3 responses)

Right, we should not blame seccomp for the failure to confine this vulnerability in tracker-miner.

I'm no C programmer, but would a better solution in this case be to use posix_spawn to start a separate process which solely reads the file being indexed and returned text. With the assumption that a separate spawned executable could be locked down stricter with seccomp than a forked thread in the same process namespace?

Still, the problem with the argument that seccomp only failed in this case because tracker-miner used it wrong, is that it is an argument of purity, like no true Scotsman...

On the other hand: OpenSSH also uses seccomp, and is implemented in C, and handles untrusted user input in a privileged environment. So, apparently for some true Scotsmen, like the OpenSSH developers, it seems to be possible to not fail to implement secure software in the C programming language. Though, that might be the exception which proves the rule?

The author of both the current fix and the previous implementation of seccomp in tracker-miners confirms (AFAIU) that the seccomp sandbox in tracker-miner was and is a compromise. Many of the libraries tracker-miner use to extract text from files were not designed with confinement and seccomp in mind. So it seems that tracker-miner had to lower the guards to get any useful output at all. Still, when that compromise was on the table, a better option would have been to abandon that aproach and find another more appropriate way forward. One that didn't compromise security for sake of features.

BTW, tracker-miner still use Gstreamer to parse files, despite Gstreamer being a known source of security issues. Reported by LWN already in 2016.
https://lwn.net/Articles/708196/

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 15:56 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

> On the other hand: OpenSSH also uses seccomp, and is implemented in C, and handles untrusted user input in a privileged environment. So, apparently for some true Scotsmen, like the OpenSSH developers, it seems to be possible to not fail to implement secure software in the C programming language. Though, that might be the exception which proves the rule?

This is a poor example, because SSH has a functional requirement to offer remote access to an authenticated/authorized user. If you sandbox it to death, then it can't do its job, so you have no choice but to take a more permissive approach. On the other hand, the vast majority of software has no such functional requirement, and therefore can be sandboxed much more aggressively than SSH servers.

Remember: There's really no such thing as absolute security. There's "harder to hack" and "easier to hack." Sandboxing is, ideally, a defense-in-depth measure. Software should be designed to avoid failing or misbehaving on malicious inputs, regardless of whether a sandbox is present, but no software is perfect, so we sandbox things to further mitigate the risk.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 10:54 UTC (Thu) by gfernandes (subscriber, #119910) [Link] (1 responses)

The OP did not blame seccomp.

The OP made a very valid point - running a thread in a sandbox, in the same process/address space where rhe main thread is NOT sandboxed, invalidates the sandbox.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 13:52 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

Indeed, that's the best TL;DR here.