It appears this change may cause intermittent slow or failed boot,
more commonly on slower/older machines, in at least Mageia and
possibly also Debian. This would indicate that while the system
is under load, system services are not completing authentication
within 5 seconds.
This change was not the main part of fixing CVE-2014-3639, but does
help to mitigate that attack. As such, increasing this timeout makes
the denial of service attack described by CVE-2014-3639 somewhat
more effective: a local user connecting to the system bus repeatedly
from many parallel processes can cause other users' attempts to
connect to take longer.
If your machine boots reliably with the shorter timeout, and
resilience against local denial of service attacks is important
to you, putting this in /etc/dbus-1/system-local.conf
or a file matching /etc/dbus-1/system.d/*.conf can restore
the lower limit:
Jacek Bukarewicz [Fri, 14 Nov 2014 18:39:38 +0000 (18:39 +0000)]
Set error when message delivery is denied due to receive rule
This makes bus_context_check_security_policy follow convention of
setting errors if function indicates failure and has error parameter.
Notable implication is that AccessDenied error will be sent if sending message
to addressed recipient is denied due to receive rule. Previously, message
was silently dropped.
This also fixes assertion failure when message is denied at addressed recipient
while sending pending auto activation messages.
Simon McVittie [Tue, 4 Nov 2014 14:41:54 +0000 (14:41 +0000)]
CVE-2014-7824: set fd rlimit to 64k for the system dbus-daemon
This ensures that our rlimit is actually high enough to avoid the
denial of service described in CVE-2014-3636 part A.
CVE-2014-7824 has been allocated for this incomplete fix.
Restore the original rlimit for activated services, to avoid
them getting undesired higher limits.
(Thanks to Alban Crequy for various adjustments which have been
included in this commit.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=85105 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Simon McVittie [Tue, 9 Sep 2014 11:44:22 +0000 (12:44 +0100)]
_dbus_read_socket_with_unix_fds: do not accept extra fds in cmsg padding
This addresses CVE-2014-3635.
If (*n_fds * sizeof (int) % sizeof (size_t)) is nonzero,
then CMSG_SPACE (*n_fds * sizeof (int)) > CMSG_LEN (*n_fds * sizeof (int)
because the SPACE includes padding to a size_t boundary, whereas the LEN
does not. We have to allocate the SPACE. Previously, we told the kernel
that the buffer size we wanted was the SPACE, not the LEN, which meant
it was free to fill the padding with additional fds: on a 64-bit
platform with 32-bit int, that's one extra fd, if *n_fds happens
to be odd.
This meant that a malicious sender could send exactly 1 fd too many,
which would make us fail an assertion if enabled, or overrun a buffer
by 1 fd otherwise.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83622 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Alban Crequy [Mon, 21 Jul 2014 16:17:11 +0000 (17:17 +0100)]
bus: enforce pending_fd_timeout
This is one of four commits needed to address CVE-2014-3637.
The bus uses _dbus_connection_set_pending_fds_function and
_dbus_connection_get_pending_fds_count to be notified when there are pending
file descriptors. A timeout per connection is armed and disarmed when the file
descriptor list is used and emptied.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is one of four commits needed to address CVE-2014-3637.
This will allow the bus to know whether there are pending file descriptors in a
DBusConnection's DBusMessageLoader.
https://bugs.freedesktop.org/show_bug.cgi?id=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[fix compilation on platforms that do not HAVE_UNIX_FD_PASSING -smcv] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Alban Crequy [Mon, 21 Jul 2014 16:34:08 +0000 (17:34 +0100)]
config: add new limit: pending_fd_timeout
This is one of four commits needed to address CVE-2014-3637.
When a file descriptor is passed to dbus-daemon, the associated D-Bus message
might not be fully sent to dbus-daemon yet. Dbus-daemon keeps the file
descriptor in the DBusMessageLoader of the connection, waiting for the rest of
the message. If the client stops sending the remaining bytes, dbus-daemon will
wait forever and keep that file descriptor.
This patch adds pending_fd_timeout (milliseconds) in the configuration to
disconnect a connection after a timeout when a file descriptor was sent but not
the remaining message.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Fri, 12 Sep 2014 14:51:39 +0000 (15:51 +0100)]
config: change DEFAULT_MESSAGE_UNIX_FDS to 16
This addresses CVE-2014-3636.
Based on a patch by Alban Crequy. Now that it's the same on all
platforms, there's little point in it being set by configure/cmake.
This change fixes two distinct denials of service:
fd.o#82820, part A
------------------
Before this patch, the system bus had the following default configuration:
- max_connections_per_user: 256
- DBUS_DEFAULT_MESSAGE_UNIX_FDS: usually 1024 (or 256 on QNX, see fd.o#61176)
as defined by configure.ac
- max_incoming_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
- max_outgoing_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
- max_message_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS = usually 1024
This means that a single user could create 256 connections and transmit
256*4096 = 1048576 file descriptors.
The file descriptors stay attached to the dbus-daemon process while they are
in the message loader, in the outgoing queue or waiting to be dispatched before
D-Bus activation.
dbus-daemon is usually limited to 65536 file descriptors (ulimit -n). If the
limit is reached and dbus-daemon needs to receive a message with a file
descriptor attached, this is signalled by recvfrom with the flag MSG_CTRUNC.
Dbus-daemon cannot recover from that error because the kernel does not have any
API to retrieve a file descriptor which has been discarded with MSG_CTRUNC.
Therefore, it closes the connection of the sender. This is not necessarily the
connection which generated the most file descriptors so it can lead to
denial-of-service attacks.
In order to prevent DoS issues, this patch reduces DEFAULT_MESSAGE_UNIX_FDS to
16:
This is less than the usual "ulimit -n" (65536) with a good margin to
accomodate the other sources of file descriptors (stdin/stdout/stderr,
listening sockets, message loader, etc.).
Distributors on non-Linux may need to configure a smaller limit in
system.conf, if their limit on the number of fds is smaller than
Linux's.
fd.o#82820, part B
------------------
On Linux, it's not possible to send more than 253 fds in a single sendmsg()
call: sendmsg() would return -EINVAL.
#define SCM_MAX_FD 253
SCM_MAX_FD changed value during Linux history:
- it used to be (OPEN_MAX-1)
- commit c09edd6eb (Jul 2007) changed it to 255
- commit bba14de98 (Nov 2010) changed it to 253
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 is fixed by keeping max_message_unix_fds <= SCM_MAX_FD.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
enable build support without systemd compatibility libraries
systemd 209 merged all the libraries to libsystemd. Old
libraries can still be enabled with --enable-compat-libs
switch in systemd but this increases the binary size.
Implement a fallback library check in case compat libraries
dont exist.
[Fixed underquoting; switched priority so we try libsystemd first -smcv] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Alban Crequy [Tue, 24 Jun 2014 16:57:14 +0000 (17:57 +0100)]
Handle ETOOMANYREFS when sending recursive fds (SCM_RIGHTS)
Since Linux commit 25888e (from 2.6.37-rc4, Nov 2010), sendmsg() on Unix
sockets returns -1 errno=ETOOMANYREFS ("Too many references: cannot splice")
when the passfd mechanism (SCM_RIGHTS) is "abusively" used recursively by
applications. A malicious client could use this to force a victim system
service to be disconnected from the system bus; the victim would likely
respond by exiting. This is a denial of service (fd.o #80163,
CVE-2014-3532).
This patch silently drops the D-Bus message on ETOOMANYREFS and does not close
the connection.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80163 Reviewed-by: Thiago Macieira <thiago@kde.org>
[altered commit message to explain DoS significance -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Wed, 11 Jun 2014 11:24:20 +0000 (12:24 +0100)]
If loader contains two messages with fds, don't corrupt the second
There were two bugs here: we would previously overwrite the unused
fds with the already-used fds instead of the other way round, and
we would copy n bytes where we should have copied n ints.
Additionally, sending crafted messages in a chosen sequence to a victim
system service could cause an invalid file descriptor to be present
when dbus-daemon tries to forward one of those crafted messages to the
victim, causing sendmsg() to fail with EBADF, which resulted in
disconnecting the victim service, which would likely respond to that
by exiting. This is a denial of service (fd.o #80469, CVE-2014-3533).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=79694
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80469 Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Alban Crequy [Tue, 20 May 2014 13:37:37 +0000 (14:37 +0100)]
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>
Роман Донченко [Wed, 30 Apr 2014 18:11:56 +0000 (19:11 +0100)]
Avoid killing all available processes if an X error arrives early on
The timeline of events in dbus-launch's main process goes something like this:
* do initial X calls
[1]
* do some other stuff
* fork
(child process starts doing some other stuff)
* return "intermediate parent" pid from fork()
* obtain bus daemon pid from bus_pid_to_launcher_pipe
[2]
* do things that might include X11 calls or killing the dbus-daemon
Meanwhile, the "babysitter" child goes like this:
* return 0 from fork()
[3]
* obtain bus daemon pid from parent process via bus_pid_to_babysitter_pipe
[4]
* do things that might include X11 calls or killing the bus daemon
Before [1] or [3], the right thing to do about an X error is to just
exit. The current implementation called kill(-1) first, which is
undesirable: it kills unrelated processes. With this change, we
just exit.
After [2] or [4], the right thing to do is to kill the dbus-daemon,
and that's what the existing code did.
Between [1] and [2], or between [3] and [4], there is no correct thing
that we can do immediately: we would have to wait for the end of the
"critical section", *then* kill the dbus-daemon. This has not yet been
implemented, so this patch relies for its correctness on the fact that
there are no libX11 calls between those points, so we cannot receive
an X error between them.
dbus-launch deserves more comments, or a reimplementation that is easier to
understand, but this change is certainly better than nothing.
Simon McVittie [Fri, 25 Apr 2014 17:51:26 +0000 (18:51 +0100)]
Try to read /etc/machine-id before inventing a new /var/lib/dbus/machine-id
It's least confusing if the two files have the same contents. systemd
already knows how to pick up our /var/lib/dbus/machine-id if it exists
and /etc/machine-id doesn't, but the converse is not currently true.
We should make it true, so that it doesn't matter what order
systemd-machine-id-setup and "dbus-uuidgen --ensure" were
invoked in.
In Debian, systemd currently Recommends dbus, so "dbus-uuidgen --ensure"
will *usually* - but not always! - run first, and the two files will
match. However, if you install systemd without dbus, and then install
dbus later, there will be a mismatch. With this change, it doesn't
matter which one is installed first: whichever one happens to come
first, it will generate the machine ID, and then the other one will
copy it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77941 Reviewed-by: Lennart Poettering
Ralf Habacker [Fri, 10 Jan 2014 01:17:22 +0000 (02:17 +0100)]
Rename shell-test to test-shell to match common test application naming scheme.
[Add its source file to SOURCES: this test was previously relying on the
Automake feature that the default value of foo_bar_SOURCES is foo-bar.c. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73495 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Ralf Habacker [Sat, 11 Jan 2014 19:51:27 +0000 (20:51 +0100)]
Rename dbus-test to test-dbus to match common test application naming scheme.
[reverted the dbus-specification part -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73495 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Matt Hoosier [Thu, 9 Jan 2014 22:15:31 +0000 (16:15 -0600)]
Don't forget allow_anonymous when merging configs
The algorithm to collapse a subsidiary config file's data into the
master data structure forgot to examine this flag.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73475 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com> Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Tue, 7 Jan 2014 12:23:10 +0000 (12:23 +0000)]
tests: don't block and wait for a debugger on abort
In general, I think developers running the tests would expect
them to terminate rather than hanging. Developers who want to debug
such an abort by attaching a debugger to a live process can still set
DBUS_BLOCK_ON_ABORT in the environment.
Ralf Habacker [Thu, 10 Oct 2013 21:42:57 +0000 (23:42 +0200)]
Use macros for test and helper executable targets on cmake build system.
The new macros add_test_executables and add helper_executables provides a
platform independent way for specifing dbus test and service applications.
On native Windows and Linux/UNIX systems the test applications are
directly runable.
When cross compiling for Windows on Linux test applications could be
executed on the Linux host system with the help of wine and activated
binfmt_misc support for wine.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41252 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
It's easier to automate these tests if they launch their own
dbus-daemon, but easier to debug them if they don't: you can launch
a dbus-daemon separately, under gdb. However, tests that need a
specially-configured dbus-daemon will have to be skipped.
Chengwei Yang [Wed, 20 Nov 2013 03:30:59 +0000 (11:30 +0800)]
Do not install systemd unit files if build without systemd
If dbus buid without systemd (--disable-systemd or no systemd libs
available when building), we expect not to install dbus systemd unit
files because they're only for systemd environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71818 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Matt Fischer [Fri, 8 Nov 2013 22:08:39 +0000 (16:08 -0600)]
Define WIN32_LEAN_AND_MEAN in Windows port
<windows.h> somewhat cloyingly attempts to include <winsock.h>
by default, which causes problems if the rest of the program
is trying to use the incompatible <winsock2.h>. The Windows
sysdep header attempts to prevent this by forcibly defining
the winsock header guard macro, so that it will not be included.
However, this does not work on MinGW because it uses a different
guard macro name.
This patch changes the code to instead define WIN32_LEAN_AND_MEAN,
which is a more portable way to ensure that <winsock.h> will not
be included.
Chengwei Yang [Fri, 6 Dec 2013 02:53:28 +0000 (10:53 +0800)]
Ensure DBusError is set if _dbus_read_nonce() fail
In _dbus_send_nonce() which call in _dbus_read_nonce() and assert on an
error is set if _dbus_read_nonce() fail. However, in _dbus_read_nonce(),
it may fail on fopen() and left error is unset. This will crash us if
assertions hasn't been disabled.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=72298 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Mon, 2 Dec 2013 04:47:47 +0000 (12:47 +0800)]
kqueue: open watched directories with close-on-exec flag
[FreeBSD and OpenBSD contributors clarified that O_CLOEXEC has been
supported for ~ 2 years on both, so for the moment we're assuming
that every platform with kqueue also has working O_CLOEXEC. Please reopen
the bug, with a tested patch that uses _dbus_fd_set_close_on_exec() instead,
if this assumption turns out to be false. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=72213 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Thu, 28 Nov 2013 01:17:38 +0000 (09:17 +0800)]
BusTransaction: remove confusing getter of connections
There is a DBusList* member of BusTransaction named "connections", while
its getter function bus_transaction_get_connections() returns
context->connections which in fact is a BusConnections pointer, this is
quite confusing. Because this is what bus_context_get_connections()
returns.
This patch call out to bus_context_get_connections() directly and remove
the then unused bus_transaction_get_connections().
https://bugs.freedesktop.org/show_bug.cgi?id=71597 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Fri, 1 Nov 2013 13:51:13 +0000 (13:51 +0000)]
_dbus_listen_unix_socket: don't try to set SO_REUSEADDR
On Hurd, the setsockopt() fails. Svante Signell confirmed that on
at least Linux and kFreeBSD, SO_REUSEADDR "succeeds" on Unix sockets,
but doesn't have any practical effect; so rather than making the
failure not issue a warning, we might as well not bother with the
syscall at all.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69492 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com> Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Wed, 18 Sep 2013 16:51:53 +0000 (17:51 +0100)]
If sendmsg() with SCM_CREDS fails with EINVAL, retry with send()
Perhaps some OSs accept and ignore attempts to send a SCM_CREDS
message on a non-Unix socket, but GNU/kFreeBSD doesn't (and presumably
FreeBSD doesn't either).
Based on a patch by Svante Signell.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69492 Tested-by: Svante Signell Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
Chengwei Yang [Sun, 1 Dec 2013 11:40:21 +0000 (19:40 +0800)]
kqueue: replace tab with space
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69332
[altered commit message to not say it fixes memory leaks -smcv] Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Tue, 19 Feb 2013 16:39:38 +0000 (16:39 +0000)]
Make sure tests run with a temporary XDG_RUNTIME_DIR
We don't want the regression tests' "session" getting mixed up in
system-wide "sessions". This doesn't actually matter yet, but it is
likely to matter in future.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61301 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
[merged with earlier line-wrapping of TESTS_ENVIRONMENT -smcv] Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Chengwei Yang [Tue, 10 Dec 2013 09:11:25 +0000 (17:11 +0800)]
Reload policy rules for completed connections
The message bus which can monitor its conf dirs for changes and reload
confs immediately if dir monitor enabled, for example, inotify in Linux,
kqueue in *BSD.
However, it doesn't apply policy rules change for completed connections,
so to apply policy rules change, the client connection has to disconnect
first and then re-connect to message bus.
For imcomplete connections, it always has the latest review of policy
rules.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39463 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Simon McVittie [Tue, 19 Feb 2013 15:40:06 +0000 (15:40 +0000)]
_dbus_check_dir_is_private_to_user: check that we own it
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61303 Reviewed-by: Chengwei Yang <chengwei.yang@intel.com> Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>