Localsearch improved their sandbox a few years ago to address CVE-2023-5557. Previously, the main thread wasn't as strictly sandboxed as the worker threads, which is how my poc for CVE-2023-43641 was able to break out of the sandbox. But their new seccomp sandbox looks extremely strong to me. If I remember correctly, they've made it so that the process that parses the untrusted files cannot even send arbitrary D-Bus messages. It's restricted to only communicating with it's parent process, using a very limited protocol. Last time I looked, I concluded that a sandbox escape would be hopeless. There are probably other applications that use gstreamer which are softer targets though.
Kev On Fri, 1 May 2026, 08:38 Demi Marie Obenour, <[email protected]> wrote: > On 4/30/26 19:59, Solar Designer wrote: > > Hi, > >>> The GStreamer library is used to parse multimedia files in Nautilus > >>> (GNOME Files), GNOME Videos, and Rhythmbox, as well as in the > >>> localsearch search engine (previously known as tracker-miners) > developed > >>> by the GNOME project. This engine is installed in many distributions as > >>> a dependency of the tracker-extract package, which GNOME uses to > >>> automatically parse metadata in new files. Among other things, this > >>> service indexes all files in the user's home directory without any user > >>> interaction. Therefore, to perform an attack, simply create a specially > >>> crafted multimedia file in the user's home directory, and the > >>> vulnerability will be exploited during its automatic indexing. > >>> > >>> In most GNOME distributions, localsearch components (tracker-miners) > are > >>> enabled by default and loaded as a hard dependency of the Nautilus file > >>> manager (GNOME Files). Starting with GNOME 46, the localsearch process > >>> runs in sandbox isolation. To disable metadata extraction, you can > >>> delete the rules files from the /usr/share/localsearch3/extract-rules/ > >>> or /usr/share/tracker3-miners/extract-rules/ directory. > > > > I don't know how good or not the mentioned "sandbox isolation" is, I'd > > welcome comments on the risks involved and potential further hardening. > > > > Alexander > > Last I checked, the sandbox was not very good. In particular, there > were seccomp rules that were thread-scoped rather than process-scoped, > allowing for sandbox escape. It might have improved, though. > > My current opinion is that it is possible to create a truly strong > sandbox on Linux that is nearly as good as hardware virtualization. > However, doing so requires severely limiting the number of system > calls available. The attack surface is then mostly limited to memory > management, which KVM also has to some degree. > -- > Sincerely, > Demi Marie Obenour (she/her/hers)
