EMBARGOED, via distros

From: Simon McVittie <simon.mcvittie@collabora.co.uk>
Date: Tue, 09 Sep 2014 19:49:06 +0100
Subject: [vs-plain] CVE request for some D-Bus DoS fixes

Hello distro security people,

We would like however many CVE IDs are felt to be appropriate for the
vulnerabilities described below, probably at least 2 (one for the file
descriptor passing issues that were introduced in 1.3.0, and one for
older issues). We intend to fix them all in the same dbus release.
Proposed unembargo date: Tuesday 16th September, timing tbd.

The referenced bugs on freedesktop.org are embargoed and non-public. If
distro security contacts or dbus maintainers would like access, please
open a freedesktop.org Bugzilla account if you don't already have one,
and tell me its associated address by private email.

Bugs listed in approximately descending order of worst-case severity.

A preliminary version of the fixes is attached. Patch 0009 and 0011 are
non-essential: 0009 silences a compiler warning in 0010, and 0011 adds a
regression test.

Thanks,
    S

----8<----

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 and Simon McVittie at Collabora Ltd. discovered and fixed
several denial-of-service flaws in the reference implementation of
dbus-daemon, the D-Bus message bus daemon. fd.o #83622 could conceivably
also be exploitable to alter data or executable code, but we do not
believe that this is likely.

fd.o #83622
-----------

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83622
Credit: discovered and fixed by Simon McVittie
Impact: denial of service, possibly heap data corruption
Access required: local
Mitigation: only unusual configurations are vulnerable
Versions believed to be vulnerable: dbus >= 1.3.0

When using the default Unix-socket-based transport, dbus-daemon accepts
and forwards file descriptors (fds) attached to D-Bus messages
("fd-passing"). If the max_message_unix_fds limit is set to an odd
number on 64-bit platforms, a malicious message-sender could pass one
more fd through the kernel than the recipient is expecting. This causes
an assertion failure and dbus-daemon crash if assertions are enabled, or
a buffer overrun by sizeof (int) otherwise.

We do not believe that the buffer overrun can be exploited to alter
data or execute arbitrary code in practice, because the buffer that is
overrun is allocated with libc realloc(), which typically rounds up odd
allocations to a multiple of 8 bytes. This would mean that the overrun
could not actually leave the allocated buffer.

This has been resolved by passing the desired maximum size to the
syscall instead of the rounded-up size of the cmsg buffer, and
discarding any excess fds if the syscall fills the cmsg buffer anyway.

fd.o#82820, part A
------------------

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820
Credit: discovered and fixed by Alban Crequy
Impact: denial of service
Access required: local
Versions believed to be vulnerable: dbus >= 1.3.0

The default limits for the system bus allowed each uid to open 256
connections to the system bus, and allowed up to 1024 fds per message,
and up to 4096 fds queued in total on each connection.

By queuing up the maximum allowed number of fds, a malicious sender
could reach the dbus-daemon's RLIMIT_NOFILE (ulimit -n, typically 65536
on Linux). This would act as a denial of service in two ways:

* new clients would be unable to connect to the dbus-daemon
* when receiving a subsequent message from a non-malicious client that
  contained a fd, dbus-daemon would receive the MSG_CTRUNC flag,
  indicating that the list of fds was truncated; kernel fd-passing APIs
  do not provide any way to recover from that, so dbus-daemon responds
  to MSG_CTRUNC by disconnecting the sender, causing denial of service
  to that sender

This has been resolved by changing the defaults so up to 16 fds are
allowed per message, and up to 64 on each connection. This means that
each uid can only queue up to 16384 fds, and denial of service is only
possible if several uids cooperate.

Since this limit might be changed further in future, the D-Bus
maintainers recommend that designers of D-Bus APIs, particularly on the
system bus, do not rely on being able to send more than one fd per message.

Distributors on operating systems with a smaller default RLIMIT_NOFILE
should consider adjusting either that limit, or the defaults in system.conf.
fd.o#82820, part B
------------------

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820
Credit: discovered and fixed by Alban Crequy
Impact: denial of service
Access required: local
Versions believed to be vulnerable: dbus >= 1.3.0

Linux allows up to 253 fds to be sent in a single sendmsg() call;
libdbus always sends all of a message's fds, and the beginning
of the message itself, in a single sendmsg() call. Combining these
two, a malicious sender could split a message across two or more
sendmsg() calls to construct a composite message with 254 or more
fds. When dbus-daemon attempted to relay that message to its
recipient in a single sendmsg() call, it would receive EINVAL,
interpret that as a fatal socket error and disconnect the recipient,
resulting in denial of service.

This has been resolved by the same change as fd.o #82820, part A.

fd.o#80559
----------

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559
Credit: discovered and fixed by Alban Crequy
Impact: denial of service
Access required: local
Versions believed to be vulnerable: dbus >= 1.3.0

By attaching the file descriptor of a D-Bus connection to a D-Bus
message and sending that message via the dbus-daemon, a malicious
process can create D-Bus connections that persist after the process that
created them has terminated. This exacerbates various patterns of
undesirable/abusive behaviour by making it impossible to terminate them
by killing processes.

This has been addressed by closing any connection that has incoming file
descriptors queued for deserialization for more than a configurable
timeout, defaulting to 2.5 minutes.

fd.o#81053
----------

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81053
Credit: discovered and fixed by Alban Crequy
Impact: denial of service
Access required: local
Versions believed to be vulnerable: all dbus releases

dbus-daemon tracks whether method call messages expect a reply, so that
unsolicited replies can be dropped. As currently implemented, if there
are n parallel method calls in progress, each method reply takes O(n)
CPU time. A malicious user can exploit this by opening the maximum
allowed number of parallel connections and sending the maximum number of
parallel method calls on each one, causing subsequent method calls to be
unreasonably slow, a denial of service.

For the short term, this has been resolved by amending the default
system bus configuration to reduce the number of parallel method calls
allowed per connection, from 8192 to 128 (i.e. from 2097152 to 32768 per
uid).

Longer-term, we plan to use better data structures to make dbus-daemon
more scalable, but this was not felt to be suitable for a minimal
security patch.

fd.o#80919
----------

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919
Credit: discovered and fixed by Alban Crequy
Impact: denial of service
Access required: local
Versions believed to be vulnerable: all dbus releases

dbus-daemon allows a small number of "incomplete" connections (64 by
default) whose identity has not yet been confirmed. When this limit has
been reached, subsequent connections are dropped. Alban's testing
indicates that one malicious process that makes repeated connection
attempts, but never completes the authentication handshake and instead
waits for dbus-daemon to time out and disconnect it, can cause the
majority of legitimate connection attempts to fail.

This has been resolved by reducing the default authentication timeout
from 30 seconds to 5 seconds, and pausing calls to accept() when the
maximum number of incomplete connections is reached, resulting in
subsequent connections being queued in the kernel (blocking in
connect()) instead of being dropped.

----8<----