user-triggerable dbus-daemon memory leak caused by CVE-2014-3477 fix
While trying to set up dbus to be able to run tests in AddressSanitizer, I found a memory leak introduced in 2014 when fixing CVE-2014-3477 (fdo#78979). If a caller sends a message to an activatable service, and the service gets auto-started, then the dbus-daemon discovers that the caller is not actually allowed to send the message to the service, it will leak one "permission denied" error.
This is technically a system bus denial of service via resource exhaustion, because someone could spam messages that each activate a service, and let the dbus-daemon leak all those errors. However, it's a weak attack with multiple mitigations, so I'm not sure whether we should treat it as a security vulnerability or just an ordinary bug. @thiago, @walters, @rhabacker: opinions?
Mitigations:
-
Each denied message is logged to the system log, making it a very noisy attack (and it's obvious which uid and even which process to blame)
-
To leak unbounded amounts of memory quickly, an attacker would need an unbounded number of activatable services that they aren't allowed to contact (but in practice there is a finite number of services)
-
To leak unbounded amounts of memory slowly, an attacker would need an activatable service, that they aren't allowed to contact, that either: has exit-on-idle behaviour, is remotely crashable, or can otherwise be induced to exit so that it can be reactivated
-
If you want to trigger swappy performance death or the OOM killer on a general-purpose Linux system, there are almost certainly easier ways!
No pull request because I don't think we can embargo those, but I'll quote the patch in a comment.