[<prev] [next>] [day] [month] [year] [list]
Message-ID: <54185FAF.6010601@collabora.co.uk>
Date: Tue, 16 Sep 2014 17:05:03 +0100
From: Simon McVittie <simon.mcvittie@...labora.co.uk>
To: oss-security@...ts.openwall.com
Subject: CVE-2014-3635 to 3639: security issues in D-Bus < 1.8.8
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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 security flaws in the reference implementation of
dbus-daemon, the D-Bus message bus daemon. fd.o #83622 is a heap
overflow and could potentially be exploited to alter data or executable
code; the rest are denial-of-service issues.
For the stable branch these are fixed in dbus 1.8.8.
For the old stable branch, these are fixed in dbus 1.6.24. Older
branches are not supported.
CVE-2014-3635 (fd.o #83622)
- ---------------------------
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83622
Category: CWE-805: Buffer Access with Incorrect Length Value
Impact: heap data corruption, worst-case: arbitrary code execution
Access required: local
Mitigation: 32-bit platforms are not vulnerable
Versions believed to be vulnerable: dbus >= 1.3.0
Credit: discovered and fixed by Simon McVittie
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.
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.
CVE-2014-3636 (fd.o#82820, parts A and B)
- -----------------------------------------
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820
Category: CWE-774: Allocation of File Descriptors or Handles
Without Limits or Throttling
Impact: denial of service
Access required: local
Versions believed to be vulnerable: dbus >= 1.3.0
Credit: discovered and fixed by Alban Crequy
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.
(Part A) 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
(Part B) Additionally, 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.
Both of these related issues have 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.
CVE-2014-3637 (fd.o#80559)
- --------------------------
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559
Category: CWE-775: Missing Release of File Descriptor or Handle after
Effective Lifetime
Impact: denial of service
Access required: local
Versions believed to be vulnerable: dbus >= 1.3.0
Credit: discovered and fixed by Alban Crequy
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.
CVE-2014-3638 (fd.o#81053)
- --------------------------
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81053
Category: CWE-407: Algorithmic Complexity
Impact: denial of service
Access required: local
Versions believed to be vulnerable: all dbus releases
Credit: discovered and fixed by Alban Crequy
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.
CVE-2014-3639 (fd.o#80919)
- --------------------------
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919
Category: CWE-774: Allocation of File Descriptors or Handles Without
Limits or Throttling
Impact: denial of service
Access required: local
Versions believed to be vulnerable: all dbus releases
Credit: discovered and fixed by Alban Crequy
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.
- --
Simon McVittie, Collabora Ltd.
on behalf of the D-Bus maintainers
-----BEGIN PGP SIGNATURE-----
iQIVAwUBVBhfoE3o/ypjx8yQAQiqjw//T5IZyg8ZTzJZWybeZfaSCkLymcYf+7rf
uCavmRs507UtDhqRkd0cuFuM0GdEZVRQsFp4jiDOyZTPLr6SWmZJuBisHBzlFsTd
1zwX72mZL5rYEvkIgnq22Jhs0RHg50Ok+tL8Ld8Lcdhm2SR4SnCubGoV+pwmid5+
1rjBZc3/YVJ38vMPJDddYKfMidIdprnbpkGtq2jP+IVZFBab2VcHY5I6oB9OzKF/
EyT4a760TJOug5aAT5Yog++lvZ+UoRf7QOLlsvgARi8HHY7rWXikbs1/Eh3I2O//
3YadlgrsgibnmnCNYMCSKaR806FaUPD9AYe0G6u8AAcOKvMBg531RSMlENkmPOW5
WklMyCyfIFMJeOFdc6Vc6G3fAaSc9KX3pbJPVb7cfnuzHWhRnye3quHo1pEWP6EL
liFBDAtRg51EaD6bMgAEvsFkUSPEltMX2i0piQ7Uh6vTXTJvndq2APlW1w8hHKKn
MoJ/z1IEwCdYD34H48ddvJZptvZgbEGnTXxhQcs23kKvWt8vYnnidKbvWxctchmC
EvPv+6Clpnyp5cSkK0UJPxV1Bcc3rzsNK+JX5HMbSadoxwOBYj2efEdedqJ0ZapZ
430xawijqcFp9jB+tEztGyK/gnHclIUKeFyawCh2DQqGsoD9tSaHYeFz3C8SxssV
hnPsLAl1KbI=
=U6YK
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
