Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMKvgcS+nx6FytpZCygev+RD6gd0qgzxBtkhn7QgkVPpf3eKqg@mail.gmail.com>
Date: Fri, 1 May 2026 09:15:05 -0700
From: Kevin Backhouse <kevin.backhouse@...il.com>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>
Subject: Re: 10+ CVEs in GStreamer

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, <demiobenour@...il.com> 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)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.