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

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 14:34 UTC (Tue) by madscientist (subscriber, #16861)
In reply to: A remote code execution vulnerability in GNOME by leromarinvit
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).

So, yes, locked down. No, not locked down to death, apparently.

to post comments

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 15:13 UTC (Tue) by leromarinvit (subscriber, #56850) [Link]

I was about to reply to myself, after noticing that in the article. But that just goes to show that tightly sandboxing arbitrary code that wasn't specifically designed with that in mind is hard, and sometimes impossible.

I'm still not convinced the idea of automatically running parsers that evidently weren't designed to run in a completely locked down environment (if they were, the sandbox could be much tighter: e.g. only read and write on already open fds, and maybe brk with a low enough memory limit set via cgroups) on untrusted data is a good one.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:16 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

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

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.