From Apertis
Jump to: navigation, search

This feature is about making D-Bus more resistant to denial of service attacks.


Identified security issues

CVE Bug Title Status upstream Status in Apertis
CVE-2014-3477 bfo#78979 security and activation: error and denial of service Public, fixed in 1.8.4 Fixed
CVE-2014-3532 bfo#80163 kick any connection off the bus with fdpassing: denial of service Public, fixed in 1.8.6 Fixed
CVE-2014-3533 bfo#80469 Misbehaviour reading a message with passing file descriptors Public, fixed in 1.8.6 Fixed
CVE-2014-3639 bfo#80919 max_incomplete_connections Public, fixed in 1.8.8 Fixed
CVE-2014-3638 bfo#81053 pending replies Public, fixed in 1.8.8 Fixed
CVE-2014-3637 bfo#80559 Immortal D-Bus connection in dbus-daemon Public, fixed in 1.8.8 Fixed
CVE-2014-3636 bfo#82820 limit the number of file descriptors in dbus-daemon Public, fixed in 1.8.8 Fixed
CVE-2014-3635 bfo#83622 potential DoS in unusual fd-passing limit configurations Public, fixed in 1.8.8 Fixed
No need bfo#80557 telepathy-gabble / dbus-glib assertion in g_value_unset Public, fixed in git for dbus-glib 0.104 Fixed
No need CHAI#2802 un-glue messages No bugs created upstream. Not a real issue, marked as worksforme.
No need bfo#81043 dbus-daemon memory grows when a process behaves abusively Identified as the same as bfo#33606 No action required


Bug Title Status upstream Status in Apertis
bfo#82346 limit D-Bus connections per process patches written but possibly controversial integrated in dbus
bfo#81469 limit D-Bus connections per cgroups or systemd unit patches written but possibly controversial The limit per cgroup or systemd unit does not reach consensus upstream yet, so I'm not asking integration for it. However, the preparatory fix for cgroups is integrated and will be upstream in Linux 3.17.

Test programs and test cases

D-Bus match rules


Bugs revealed by this test case:

Component Upstream
Bluez Fixed in git
ConnMan Fixed in git
PacRunner Fixed in git
Ofono Fixed in git
Avahi Reported, but not merged

D-Bus reply time

QA/Test_Cases/dbus-dos-reply-time: check the reply time (ping-pong) when traffic is generated

Links to some related bugs

Bug Title Notes
bfo#34140 message-spamming tool Integrated. Help to write our DoS test cases
bfo#80603 dbus-monitor showing fds Integrated. Help debugging DoS related to fd-passing
bfo#24307 bfo#80759 bgo#735167 GetConnectionMatchRules Integrated. Help debugging DoS related to bad match rules
bfo#33606 dbus-daemon memory usage ballooning if a client is slow to read Issue part of dbus architecture. It will not get fixed here.

Post 2014Q3 issues

The issues mentioned above were fixed for the 2014Q3 release. But a couple of new issues were discovered after the 2014Q3 release:

CVE Bug Title Status upstream Status in Apertis
CVE-2014-7824 bfo#85105 Increase file descriptor limit to avoid DoS Fixed in dbus 1.8.10 Integration requested
Not requested bfo#85253 Linux limiting inflight fds per user: consequences on dbus-daemon security Hidden, not fixed Not fixed

fd-passing on SAS

In future versions of D-Bus , it will be possible to restrict fd-passing. This is useful because fd-passing is the source of a lot of potential denial of service issues.

list of fd-passing usage

On SAS, file descriptors are passed on D-Bus by the following components:

  • interface org.bluez.HandsfreeAgent, method NewConnection(filedescriptor fd, uint16 version), implemented by ofono, called by bluez.
  • list to be completed... see this upstream list

how to restrict fd-passing in the D-Bus policy

The upstream patches for send_fds, receive_fds, send_broadcast are not yet released so the syntax can change. See also comment 19 and 20. However, it should be something like the following.

It will be possible to restrict fd-passing in /etc/dbus-1/system.conf by default:

<deny send_fds="true" />

And then allow it only for specific services in /etc/dbus-1/system.d/*.conf. Example of change in bluetooth.conf:

-<allow send_interface="org.bluez.HandsfreeAgent"/>
+<allow send_fds="true" send_destination="org.ofono" send_interface="org.bluez.HandsfreeAgent" />

Note that any 'allow' rule of type 'send' without a 'send_fds' attribute in /etc/dbus-1/system.d/*.conf will allow fd-passing. So it would be necessary to do this kind of change in e.g. org.freedesktop.RealtimeKit1.conf:

 <policy context="default">
-  <allow send_destination="org.freedesktop.RealtimeKit1"/>
+  <allow send_destination="org.freedesktop.RealtimeKit1" send_fds="false"/>

Since rtkit-daemon is not supposed to receive file descriptors, we might not want to allow fd-passing implicitely.

Personal tools