- May 14, 2015
-
-
Simon McVittie authored
-
- May 12, 2015
-
-
Simon McVittie authored
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
-
- May 08, 2015
-
-
Ralf Habacker authored
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
-
Simon McVittie authored
This reverts commit 21a7873f. 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
-
- May 06, 2015
-
-
Ralf Habacker authored
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>
-
Ralf Habacker authored
Reported by Coverity: CID: Unchecked return value (CHECKED_RETURN) Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
-
Ralf Habacker authored
dbus_message_demarshal: Fix calling _dbus_string_append_len without checking return value (CID 54690). Reported by Coverity: CID 54690: Unchecked return value (CHECKED_RETURN) Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
-
- May 05, 2015
-
-
Simon McVittie authored
-
Adrian Szyndela authored
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>
-
Adrian Szyndela authored
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>
-
- Apr 28, 2015
-
-
Ralf Habacker authored
Reported by Coverity: CID 54749: Missing unlock (LOCK) Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90021 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
-
- Apr 15, 2015
-
-
Ralf Habacker authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=87999 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> (cherry picked from commit fa1ada44) Conflicts: cmake/test/CMakeLists.txt test/Makefile.am
-
- Apr 13, 2015
-
-
Ralf Habacker authored
The watches added on connection setup should be removed on shutdown. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90005 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
-
Ralf Habacker authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90004 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
-
- Feb 09, 2015
-
-
Ralf Habacker authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=87999 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk> (cherry picked from commit 795ea300)
-
- Feb 05, 2015
-
-
Simon McVittie authored
-
- Feb 04, 2015
-
-
Simon McVittie authored
-
Simon McVittie authored
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
-
Simon McVittie authored
-
- Jan 05, 2015
-
-
Simon McVittie authored
-
Simon McVittie authored
dbus-1.8.14
-
Ralf Habacker authored
We need to include 'test' subdir in any case not only when using glib. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88009 Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
-
Ralf Habacker authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71297 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
-
- Jan 01, 2015
-
-
Simon McVittie authored
-
Simon McVittie authored
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]
-
Simon McVittie authored
Reviewed-by: Thiago Macieira <thiago@kde.org>
-
Simon McVittie authored
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]
-
Simon McVittie authored
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]
-
- Dec 23, 2014
-
-
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=77008 Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
-
- Nov 24, 2014
-
-
Simon McVittie authored
-
Simon McVittie authored
-
- Nov 22, 2014
-
-
Simon McVittie authored
This reverts commit 54d26df5. 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
-
Simon McVittie authored
This is a symptom of either a denial of service attack, or a serious performance problem. Either way, sysadmins should know. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
-
- Nov 14, 2014
-
-
Simon McVittie authored
We now have a private mailing list that can be the security contact.
-
Simon McVittie authored
-
Jacek Bukarewicz authored
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
-
- Nov 10, 2014
-
-
Simon McVittie authored
-
Simon McVittie authored
-
- Nov 06, 2014
-
-
Simon McVittie authored
-
Simon McVittie authored
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>
-