Because D-Bus serializes the string faithfully, the shell will execute the injection. Modern services should use execv or API calls, but legacy dbus-1.0 wrappers often used popen() . One of the most famous dbus-1.0 -adjacent exploits involved PolKit (pkexec). While not a D-Bus bug, the attack surface was D-Bus. An unprivileged user could send a carefully crafted D-Bus message to org.freedesktop.PolicyKit1 , causing a race condition where the privilege elevation was granted to a different process than the one requesting it.
If the service does: sprintf(command, "rsync -av %s %s:/backup/", source_path, dest_host) An attacker sends: source_path = "/etc/shadow; id" (type STRING ) and dest_host = "localhost" . dbus-1.0 exploit
# Craft a method call to a method that normally requires admin # but is mis-policy'd: "SetProperty" on the adapter to force discoverable msg = Message( destination='org.bluez', path='/org/bluez/hci0', interface='org.freedesktop.DBus.Properties', member='Set', signature='ssv', body=['org.bluez.Adapter1', 'Discoverable', Variant('b', True)] ) Because D-Bus serializes the string faithfully, the shell
busctl --system tree org.bluez We find /org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX – a connected device. While not a D-Bus bug, the attack surface was D-Bus
Yet, for all its ubiquity, D-Bus is a blind spot for many penetration testers and red teams. We scan for open SMB ports, we hunt for SUID binaries, but we rarely ask: Can we talk to the system bus?
A typical vulnerable rule looks like this (simplified):