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

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 13:10 UTC (Wed) by fredrik (subscriber, #232)
In reply to: A remote code execution vulnerability in GNOME by roc
Parent article: A remote code execution vulnerability in GNOME

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/

to post comments

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.