diff options
author | Alban Crequy <alban.crequy@collabora.co.uk> | 2014-05-20 14:37:37 +0100 |
---|---|---|
committer | Simon McVittie <simon.mcvittie@collabora.co.uk> | 2014-06-05 14:36:17 +0100 |
commit | 24c590703ca47eb71ddef453de43126b90954567 (patch) | |
tree | 7ecc1e1d7f4248b97ce0a22ba7072f1f6ef8ed90 /doc | |
parent | 416898324decb7b6d86083a6e2ddc71e8d835feb (diff) |
CVE-2014-3477: deliver activation errors correctly, fixing Denial of Service
How it should work:
When a D-Bus message activates a service, LSMs (SELinux or AppArmor) check
whether the message can be delivered after the service has been activated. The
service is considered activated when its well-known name is requested with
org.freedesktop.DBus.RequestName. When the message delivery is denied, the
service stays activated but should not receive the activating message (the
message which triggered the activation). dbus-daemon is supposed to drop the
activating message and reply to the sender with a D-Bus error message.
However, it does not work as expected:
1. The error message is delivered to the service instead of being delivered to
the sender. As an example, the error message could be something like:
An SELinux policy prevents this sender from sending this
message to this recipient, [...] member="MaliciousMethod"
If the sender and the service are malicious confederates and agree on a
protocol to insert information in the member name, the sender can leak
information to the service, even though the LSM attempted to block the
communication between the sender and the service.
2. The error message is delivered as a reply to the RequestName call from
service. It means the activated service will believe it cannot request the
name and might exit. The sender could activate the service frequently and
systemd will give up activating it. Thus the denial of service.
The following changes fix the bug:
- bus_activation_send_pending_auto_activation_messages() only returns an error
in case of OOM. The prototype is changed to return TRUE, or FALSE on OOM
(and its only caller sets the OOM error).
- When a client is not allowed to talk to the service, a D-Bus error message
is pre-allocated to be delivered to the client as part of the transaction.
The error is not propagated to the caller so RequestName will not fail
(except on OOM).
[fixed a misleading comment -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78979
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Diffstat (limited to 'doc')
0 files changed, 0 insertions, 0 deletions