[Pkg-utopia-maintainers] Bug#1144129: xdg-dbus-proxy: GHSA-r7hp-698j-2h6c: filtering for broadcast messages bypasses path/interface/member checks

[Simon McVittie]

Package: xdg-dbus-proxy
Version: 0.1.6-1
Severity: important
Tags: security pending
X-Debbugs-Cc: Debian Security Team <team at security.debian.org>

In xdg-dbus-proxy versions 0.1.6 and 0.1.7 (only), filtering for 
broadcast messages bypasses the intended path/interface/member checks. A 
malicious or compromised Flatpak app could monitor any broadcast signal 
on the D-Bus session bus or the AT-SPI bus, obtaining information that 
was not intended to be available to it.

Similarly, if a non-Flatpak app framework uses

    xdg-dbus-proxy … --broadcast=…

or

    xdg-dbus-proxy … --call=…

then a compromised or malicious app in that framework could monitor 
broadcast signals on the affected bus.

This is fixed in upstream release 0.1.8.

Note that fixing this may cause regressions unless app frameworks are
updated appropriately:

  * Flatpak versions 1.15.9 and up attempt to allow sandboxed apps to
    receive two broadcast signals on the AT-SPI bus, but the --broadcast
    command-line options that Flatpak passed to xdg-dbus-proxy were
    incorrect. As a result, fixing this vulnerability will regress
    accessibility features for Flatpak apps, unless Flatpak is also updated
    to correct its --broadcast rules. This is fixed in Flatpak versions
    1.18.1 and newer (coming soon) by commit
    "run-dbus: Correct --broadcast rules for the AT-SPI bus".
  * If a legitimate Flatpak app was relying on being able to receive
    broadcast signals from a service for which it did not have a --talk-name
    or --system-talk-name permission, this would accidentally have worked as
    a result of this vulnerability, but will fail after this vulnerability
    is fixed. This can be addressed by updating any affected Flatpak apps'
    metadata to request an appropriate --talk-name or --system-talk-name
    permission.
  * If other app frameworks use xdg-dbus-proxy, the framework or its apps
    might experience similar regressions, which can be addressed by adding
    suitable --broadcast or --talk rules to its xdg-dbus-proxy invocation.

Preparing 0.1.8-1 for unstable soon, and I've already contacted the 
security team regarding a trixie backport.

    smcv