A normal DBusConnection will automatically reply to o.fd.Peer
messages such as Ping. We don't want this: we'll
confuse everyone else by replying to messages that weren't
intended for us.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90952
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
(cherry picked from commit d9ee040d0b,
commit message adjusted to describe the impact in versions < 1.9)
Conflicts:
tools/dbus-monitor.c
Reply message was not unreferenced when GetConnectionCredentials
handler was successful.
Signed-off-by: Jacek Bukarewicz <j.bukarewicz@samsung.com>
[smcv: changed bus_message_unref() to dbus_message_unref()]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=91008
DBUS_COOKIE_SHA1 is dependent on unguessable strings, i.e.
indirectly dependent on high-quality pseudo-random numbers
whereas EXTERNAL authentication (credentials-passing)
is mediated by the kernel and cannot be faked.
On Windows, EXTERNAL authentication is not available,
so we continue to use the hard-coded default (all
authentication mechanisms are tried).
Users of tcp: or nonce-tcp: on Unix will have to comment
this out, but they would have had to use a special
configuration anyway (to set the listening address),
and the tcp: and nonce-tcp: transports are inherently
insecure unless special steps are taken to have them
restricted to a VPN or SSH tunnelling.
Users of obscure Unix platforms (those that trigger
the warning "Socket credentials not supported on this Unix OS"
when compiling dbus-sysdeps-unix.c) might also have to
comment this out, or preferably provide a tested patch
to enable credentials-passing on that OS.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
This patch is based on the fix for 'Field reader.array_len_offset is
uninitialized'
Reported by Coverity: CID 54754, 54772, 54773: Uninitialized scalar
variable (UNINIT)
[smcv: also re-order how the class is set when we recurse, so that
the sub-reader's class doesn't end up NULL]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021
This reverts commit 21a7873f20.
This appears to cause a segfault, presumably resulting from something
assuming that reader_init() would not reinitialize all fields:
#0 0x00007ffff7b74777 in _dbus_type_reader_get_current_type (reader=reader@entry=0x7fffffffda50) at .../dbus/dbus-marshal-recursive.c:791
#1 0x00007ffff7b719d0 in _dbus_header_cache_check (header=<optimized out>)
at .../dbus/dbus-marshal-header.c:209
#2 0x00007ffff7b719d0 in _dbus_header_cache_check (header=header@entry=0x624658, field=field@entry=6) at .../dbus/dbus-marshal-header.c:250
#3 0x00007ffff7b72884 in _dbus_header_get_field_basic (header=header@entry=0x624658, field=field@entry=6, type=type@entry=115, value=value@entry=0x7fffffffdbd8) at .../dbus/dbus-marshal-header.c:1365
#4 0x00007ffff7b7d8c2 in dbus_message_get_destination (message=message@entry=0x624650) at .../dbus/dbus-message.c:3457
#5 0x00007ffff7b67be6 in _dbus_connection_send_preallocated_unlocked_no_update (connection=connection@entry=0x6236d0, preallocated=0x0,
preallocated@entry=0x6234c0, message=message@entry=0x624650, client_serial=client_serial@entry=0x7fffffffdcbc)
at .../dbus/dbus-connection.c:2017
This patch is based on the fix for 'Field reader.array_len_offset is uninitialized'
Reported by Coverity: CID 54754, 54772, 54773: Uninitialized scalar variable (UNINIT)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The overall problem here is that DBusCounter is indirectly linked
to a DBusConnection, but is not actually guaranteed to be protected by
that connection's mutex; and a DBusMessage can carry a reference to the
DBusCounter, resulting in freeing that DBusMessage having an effect on
the DBusCounter.
Making the refcount atomic would not be a sufficient fix, since it would
not protect the notify function: _dbus_counter_notify() could be called
indirectly by dbus_message_unref(), in an arbitrary thread that does not
hold the DBusConnection's lock, at the same time that the holder
of the DBusConnection lock calls _dbus_transport_set_max_message_size().
[smcv: added commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89297
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The other code paths that ref or unref a transport are protected by
the DBusConnection's lock. This function already used that lock,
but for a narrower scope than the refcount manipulation.
live_messages_notify() could be triggered by unreffing messages
that originated from the same connection in a different thread.
[smcv: added commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90312
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Without either this rule or better checking in dbus-daemon, non-systemd
processes can make dbus-daemon think systemd failed to activate a system
service, resulting in an error reply back to the requester.
This is redundant with the fix in the C code (which I consider to be
the real solution), but is likely to be easier to backport.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88811
Reviewed-by: Alban Crequy
Reviewed-by: David King
Reviewed-by: Philip Withnall
These function calls are not a privilege escalation risk like
UpdateActivationEnvironment, but they might provide sensitive
information or be enhanced to provide sensitive information
in future, so the default system.conf locks them down to root-only.
Apply the same canonical-object-path hardening as for
UpdateActivationEnvironment.
We do not apply the uid check here because they are less dangerous
than UpdateActivationEnvironment, and because the ability to unlock
these function calls for specific uids is a documented configuration
for developers.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[added missing #include; extended commit message -smcv]
As with the previous commit, this is probably not actually privilege
escalation due to the use of an activation helper that cleans up its
environment, but let's be extra-careful here.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[adjusted commit message -smcv]
UpdateActivationEnvironment is the one dbus-daemon API call that is
obviously dangerous (it is intended for the session bus),
so the default system.conf does not allow anyone to call it.
It has recently come to the D-Bus maintainers' attention that some
system services incorrectly install D-Bus policy rules that allow
arbitrary method calls to any destination as long as they have a
"safe" object path. This is not actually safe: some system services
that use low-level D-Bus bindings like libdbus, including dbus-daemon
itself, provide the same API on all object paths.
Unauthorized calls to UpdateActivationEnvironment are probably just
resource consumption rather than privilege escalation, because on
the system bus, the modified environment is only used to execute
a setuid wrapper that avoids LD_PRELOAD etc. via normal setuid
handling, and sanitizes its own environment before executing
the real service. However, it's safest to assume the worst and
treat it as a potential privilege escalation.
Accordingly, as a hardening measure to avoid privilege escalation on
systems with these faulty services, stop allowing calls to
("/com/example/Whatever",
"org.freedesktop.DBus.UpdateActivationEnvironment")
and only allow ("/org/freedesktop/DBus",
"org.freedesktop.DBus.UpdateActivationEnvironment").
We deliberately continue to provide read-only APIs like
GetConnectionUnixUser at all object paths, for backwards compatibility.
Reviewed-by: Thiago Macieira <thiago@kde.org>
[adjusted commit message to note that this is probably only DoS -smcv]
This reverts commit 54d26df52b.
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:
<busconfig>
<limit name="auth_timeout">5000</limit>
</busconfig>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
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.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86194
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>
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>
