Date: Tue, 10 Jun 2014 18:28:52 +0100 From: Simon McVittie <simon.mcvittie@...labora.co.uk> To: oss-security@...ts.openwall.com, "dbus@...ts.freedesktop.org" <dbus@...ts.freedesktop.org> CC: Alban Créquy <alban.crequy@...labora.co.uk> Subject: CVE-2014-3477 (fd.o#78979): local DoS in dbus-daemon D-Bus <http://www.freedesktop.org/wiki/Software/dbus/> is an asynchronous inter-process communication system, commonly used for system services or within a desktop session on Linux and other operating systems. Alban Crequy at Collabora Ltd. discovered and fixed a denial-of-service flaw in dbus-daemon, part of the reference implementation of D-Bus. Additionally, in highly unusual environments the same flaw could lead to a side channel between processes that should not be able to communicate. On the stable branch, this is fixed in version 1.8.4: http://dbus.freedesktop.org/releases/dbus/dbus-1.8.4.tar.gz http://dbus.freedesktop.org/releases/dbus/dbus-1.8.4.tar.gz.asc On the previous stable branch, this is fixed in version 1.6.20: http://dbus.freedesktop.org/releases/dbus/dbus-1.6.20.tar.gz http://dbus.freedesktop.org/releases/dbus/dbus-1.6.20.tar.gz.asc Distributions supporting other versions should base their changes on this commit: http://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.8&id=24c590703ca47eb71ddef453de43126b90954567 Summary: If a client C1 is prohibited from sending a message to a service S1, and S1 is not currently running, then C1 can attempt to send a message to S1's well-known bus name, causing dbus-daemon to start S1 . When S1 has started and obtained its well-known bus name, the dbus-daemon evaluates its security policy, decides that it will not deliver the message to S1, and constructs an AccessDenied error. However, instead of sending that AccessDenied error reply to C1 as a reply to the denied message, dbus-daemon incorrectly sends it to S1 as a reply to the request to obtain its well-known bus name. Impact A: denial of service. S1 will fail to initialize, and exit, denying service to legitimate clients of S1. Impact B: side channel. In environments where C1 and S1 are untrusted and are administratively prohibited from communicating, S1 could also use these incorrectly-directed error messages as a side channel to receive information from C1. Mitigations: Impact A: if a legitimate client was actively using S1, S1 would already have been started, so C1 can only deny service to a legitimate client that only recently became active. Impact B: in practice processes sharing a system bus can typically communicate in other ways (non-D-Bus IPC mechanisms, files in /tmp, etc.), so impact B is not relevant on normal systems. It might be relevant on systems when an LSM such as SELinux is used in a highly restrictive configuration. Footnotes:  This is perhaps unexpected, but the dbus-daemon is behaving as designed: it cannot necessarily evaluate which security policies it should apply to S1 until S1 has actually connected back to dbus-daemon, because S1 might change its uid, SELinux context, etc. during startup. The conceptual model is that activatable services are always running, and that the dbus-daemon delaying their startup until they are actually needed is a form of lazy evaluation. As such, the D-Bus maintainers do not consider this to be a bug or vulnerability.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ