We're hiring!
*

Improving the security of D-Bus

Alban Crequy avatar

Alban Crequy
October 06, 2014

Share this post:

In the last months, I have been working on improving the security of D-Bus, mainly to make it more resistant to denial of service attacks. This work was sponsored by Collabora. 

Eight security issues were discovered, fixed and attributed a CVE. They were found by looking at the source code (in D-Bus and Linux' af_unix implementation), checking existing issues in the D-Bus bugzilla and a bit of luck. 

Security issues fixed in D-Bus

  • CVE-2014-3477 (Bug #78979): dbus-daemon sent an AccessDenied error to the service instead of a client when the client is prohibited from accessing the service, which allowed local users to cause a denial of service (initialization failure and exit) or possibly conduct a side-channel attack via a D-Bus message to an inactive service.
  • CVE-2014-3532 (Bug #80163): when running on Linux 2.6.37-rc4 or later, local users could cause a denial of service (system-bus disconnect of other services or applications) by sending a message containing a file descriptor, then exceeding the maximum recursion depth before the initial message is forwarded.
  • CVE-2014-3533 (Bug #80469): dbus-daemon allowed local users to cause a denial of service (disconnect) via a certain sequence of crafted messages that caused the dbus-daemon to forward a message containing an invalid file descriptor.
  • CVE-2014-3635 (Bug #83622): an off-by-one error in dbus-daemon allowed remote attackers to cause a denial of service (dbus-daemon crash) or possibly execute arbitrary code by sending one more file descriptor than the limit, which triggered a heap-based buffer overflow or an assertion failure.
  • CVE-2014-3636 (Bug #82820): a denial-of-service vulnerability in dbus-daemon allowed local attackers to prevent new connections to dbus-daemon, or disconnect existing clients, by exhausting descriptor limits.
  • CVE-2014-3637 (Bug #80559): malicious local users could create D-Bus connections to dbus-daemon which could not be terminated by killing the participating processes, resulting in a denial-of-service vulnerability.
  • CVE-2014-3638 (Bug #81053): dbus-daemon suffered from a denial-of-service vulnerability in the code which tracks which messages expect a reply, allowing local attackers to reduce the performance of dbus-daemon.
  • CVE-2014-3639 (Bug #80919): dbus-daemon did not properly reject malicious connections from local users, resulting in a denial-of-service vulnerability.

 

Other fixes

In addition to fixing specific bugs, I also explored ideas to restrict the number of D-Bus connections a process or a cgroup could create. After discussions with upstream, those ideas were not retained upstream. But while working on cgroups, my patch for parsing /proc/pid/cgroupwas accepted in Linux 3.17. 

Identify bogus D-Bus match rules

D-Bus security issues are not all in dbus-daemon: they could be in applications misusing D-Bus. One common mistake done by applications is to receive a D-Bus signal and handle it without checking it was really sent by the expected sender. It seems impossible to check the code of all applications potentially using D-Bus in order to see if such a mistake is done. Instead of looking the code of random applications, my approach was to add a new method GetAllMatchRules in dbus-daemon to retrieve all match rules and look for suspicious patterns. For example, a match rule for NameOwnerChanged signals that does not filter on the sender of such signals is suspicious and it worth checking the source code of the applications to see if it is legitimate. With this method, I was able to fix bugs in BluezConnManPacrunnerOfono and Avahi

GetAllMatchRules is released in dbus 1.9.0 and it is now possible to try it without recompiling D-Bus to enable the feature. I have used a script to tell me which processes register suspicious match rules. I would like if there was a way to do that in a graphical interface. It's not ready yet, but I started a patch in D-Feet.

Original post

Related Posts

Related Posts

Comments (1)

  1. Jayaraj Chanku:
    Mar 28, 2018 at 04:18 PM

    Thanks for sharing this data, it will be a great help to avoid further bugs.

    Reply to this comment

    Reply to this comment


Add a Comment






Allowed tags: <b><i><br>Add a new comment:


Search the newsroom

Latest Blog Posts

Virglrenderer and the state of virtualized virtual worlds

28/08/2019

With the release of virglrenderer 0.8.0, getting accelerated OpenGL within a virtual machine (VM) made a big leap forward. Since virglrenderer-0.7.0,…

ROCK Pi and an easy place: Panfrost & Wayland on a Rockchip board

06/08/2019

Ongoing work on the reverse-engineered Panfrost OpenGL ES driver for Arm Mali GPUs has turned the RK3399 SoC into a very attractive platform…

What's new in OpenXR 1.0 & Monado?

02/08/2019

As part of its unwavering commitment to open source and open standards, Collabora is proud to be part of bringing the recently-released…

Zink: Summer Update & SIGGRAPH 2019

25/07/2019

There's been quite a few updates to Zink, an OpenGL implementation on top of Vulkan, since I last wrote about it. Here's an overview of…

GStreamer in Oslo

18/07/2019

A little over a month and a half ago, Collaborans including Aaron Boxer, George Kiagiadakis, Guillaume Desmottes, Stéphane Cerveau and myself…

GNOME meets Panfrost

26/06/2019

In my last Panfrost blog post, I announced my internship goal: improve Panfrost to run GNOME3. GNOME is a popular Linux desktop making heavy…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2019. All rights reserved. Website sitemap.