Alban Crequy of Collabora Ltd. discovered a denial of service flaw in dbus-daemon. If a client (C1) was prohibited from sending a message to a service (S1), and S1 was not currently running, then C1 could attempt to send a message to S1's well-known bus name, causing dbus-daemon to start S1. When S1 had started and obtained its well-known bus name, the dbus-daemon evaluated its security policy, decided that it would not deliver the message to S1, and constructed an AccessDenied error. Instead of sending that AccessDenied error reply to C1 as a reply to the denied message, dbus-daemon incorrectly sent it to S1 as a reply to the request to obtain its well-known bus name. This would cause S1 to fail to initialize and exit, denying service to other legitimate clients of S1.
As well, this opens up the possibility of a side channel where, in an environment where C1 and S1 are untrusted and were administratively prohibited from communicating, S1 could use these incorrectly-directed error messages as a side channel to receive information from C1. This scenario is only really relevant on systems where an LSM such as SELinux was used in a highly restrictive configuration, because in practice a system bus could typically communicate in other ways (such as non-D-Bus IPC mechanisms, files in /tmp, etc.).
Red Hat would like to thank D-Bus upstream for reporting this issue. Upstream acknowledges Alban Crequy of Collabora Ltd. as the original reporter.
Created attachment 902257 [details]
Upstream has noted that this affects dbus as far back as 1.0.
This issue is public now:
It has been fixed in upstream versions 1.8.4 and 1.6.20.
Created dbus tracking bugs for this issue:
Affects: fedora-all [bug 1107886]
Created mingw-dbus tracking bugs for this issue:
Affects: fedora-all [bug 1117395]
This issue affect the dbus package in Red Hat Enterprise Linux 5, 6, 7. Red Hat Product Security has rated this issue as having Moderate security impact, a future update my address this flaw in Red Hat Enterprise Linux 6 and 7. This issue is not planned to be fixed in Red Hat Enterprise Linux 5 as it is now in Production 3 Phase of the support and maintenance life cycle, https://access.redhat.com/support/policy/updates/errata/