Package: dbus / 1.2.24-4+squeeze3

Metadata

Package Version Patches format
dbus 1.2.24-4+squeeze3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
00_dbus quiesce startup errors.patch | (download)

bus/config-parser.c | 14 12 + 2 - 0 !
1 file changed, 12 insertions(+), 2 deletions(-)

---
01_no fatal warnings.patch | (download)

dbus/dbus-internals.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---
10_dbus 1.0.1 generate xml docs.patch | (download)

Doxyfile.in | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---
11 589662 reload kqueue.patch | (download)

bus/dir-watch-kqueue.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 kqueue set_watched_dirs: fix termination condition

num_fds is the number of elements of dirs currently in use. This bug
meant that encountering a previously un-watched directory would cause j
to increment forever, and so dirs[j] would eventually segfault.

(I've checked the corresponding code for inotify, and it's correct. I
wonder if some of the duplication could be eliminated.)

Thanks to Pablo Martí Gamboa <pmarti@warp.es> for reporting this issue!

12 CVE 2010 4352 reject deeply nested variants.patch | (download)

dbus/dbus-marshal-validate.c | 30 25 + 5 - 0 !
dbus/dbus-marshal-validate.h | 1 1 + 0 - 0 !
dbus/dbus-message-factory.c | 65 65 + 0 - 0 !
doc/dbus-specification.xml | 14 8 + 6 - 0 !
4 files changed, 99 insertions(+), 11 deletions(-)

 [patch 1/4] cve 2010-4352: reject deeply nested variants

Add DBUS_INVALID_NESTED_TOO_DEEPLY validity problem and a test that
should generate it.

Previously, we rejected deep nesting in the signature, but
variants allow dynamic message nesting, conditional only
on the depth of the message body.

The nesting limit is 64, which was also the limit in static
signatures.  Empirically, dynamic nesting depth observed on my
Fedora 14 system doesn't exceed 2; 64 is really a huge limit.

https://bugs.freedesktop.org/show_bug.cgi?id=32321

Signed-Off-By: Colin Walters <walters@verbum.org>
Signed-off-by: Will Thompson <will.thompson@collabora.co.uk>

Conflicts:

	dbus/dbus-marshal-validate.h

13 629938 _dbus_header_byteswap.patch | (download)

dbus/dbus-marshal-header.c | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 [patch] _dbus_header_byteswap: change the first byte of the message,
 not just the struct member

This has been wrong approximately forever, for instance see:
http://lists.freedesktop.org/archives/dbus/2007-March/007357.html

This prevents a local DoS, in which users can disconnect a system service
from the system bus by sending a non-native-endian message to it.

CVE: CVE-2011-2200
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38120
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629938
0001 CVE 2012 3524 Don t access environment variables or .patch | (download)

configure.in | 2 1 + 1 - 0 !
dbus/dbus-keyring.c | 7 7 + 0 - 0 !
dbus/dbus-sysdeps-unix.c | 62 61 + 1 - 0 !
dbus/dbus-sysdeps.c | 5 5 + 0 - 0 !
dbus/dbus-sysdeps.h | 1 1 + 0 - 0 !
5 files changed, 75 insertions(+), 2 deletions(-)

 [patch 1/5] cve-2012-3524: don't access environment variables or run
 dbus-launch when setuid

This matches a corresponding change in GLib.  See
glib/gutils.c:g_check_setuid().

Some programs attempt to use libdbus when setuid; notably the X.org
server is shipped in such a configuration. libdbus never had an
explicit policy about its use in setuid programs.

I'm not sure whether we should advertise such support.  However, given
that there are real-world programs that do this currently, we can make
them safer with not too much effort.

Better to fix a problem caused by an interaction between two
components in *both* places if possible.

How to determine whether or not we're running in a privilege-escalated
path is operating system specific.  Note that GTK+'s code to check
euid versus uid worked historically on Unix, more modern systems have
filesystem capabilities and SELinux domain transitions, neither of
which are captured by the uid comparison.

On Linux/glibc, the way this works is that the kernel sets an
AT_SECURE flag in the ELF auxiliary vector, and glibc looks for it on
startup.  If found, then glibc sets a public-but-undocumented
__libc_enable_secure variable which we can use.  Unfortunately, while
it *previously* worked to check this variable, a combination of newer
binutils and RPM break it:
http://www.openwall.com/lists/owl-dev/2012/08/14/1

So for now on Linux/glibc, we fall back to the historical Unix version
until we get glibc fixed.

On some BSD variants, there is a issetugid() function.  On other Unix
variants, we fall back to what GTK+ has been doing.

Reported-by: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: Colin Walters <walters@verbum.org>
[backported to 1.2 -smcv]
0002 hardening Ensure _dbus_check_setuid is initialized t.patch | (download)

dbus/dbus-sysdeps-pthread.c | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 [patch 2/5] hardening: ensure _dbus_check_setuid() is initialized
 threadsafe manner

This is a highly theoretical concern, but we might as well.

https://bugs.freedesktop.org/show_bug.cgi?id=52202

0003 hardening Remove activation helper handling for DBUS.patch | (download)

bus/activation-helper.c | 14 1 + 13 - 0 !
1 file changed, 1 insertion(+), 13 deletions(-)

 [patch 3/5] hardening: remove activation helper handling for
 DBUS_VERBOSE

It's not really useful.

See https://bugs.freedesktop.org/show_bug.cgi?id=52202#c17

0004 activation helper Ensure DBUS_STARTER_ADDRESS is set.patch | (download)

bus/activation-helper.c | 16 5 + 11 - 0 !
1 file changed, 5 insertions(+), 11 deletions(-)

 [patch 4/5] activation-helper: ensure dbus_starter_address is set
 correctly

The fix for CVE-2012-3524 filters out all environment variables if
libdbus is used from a setuid program, to prevent various spoofing
attacks.

Unfortunately, the activation helper is a setuid program linking
libdbus, and this creates a regression for launched programs using
DBUS_STARTER_ADDRESS, since it will no longer exist.

Fix this by hardcoding the starter address to the default system bus
address.

Signed-off-by: Geoffrey Thomas <gthomas@mokafive.com>
Signed-off-by: Colin Walters <walters@verbum.org>
CVE 2014 3638.patch | (download)

bus/config-parser.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch 01/10] system bus limit: use max_replies_per_connection=128 by
 default

This addresses CVE-2014-3638.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81053
CVE 2014 3639.patch | (download)

bus/bus.c | 37 37 + 0 - 0 !
bus/bus.h | 1 1 + 0 - 0 !
bus/connection.c | 46 23 + 23 - 0 !
bus/connection.h | 1 1 + 0 - 0 !
dbus/dbus-server-protected.h | 5 2 + 3 - 0 !
dbus/dbus-server.c | 19 5 + 14 - 0 !
dbus/dbus-watch.c | 21 21 + 0 - 0 !
dbus/dbus-watch.h | 2 2 + 0 - 0 !
8 files changed, 92 insertions(+), 40 deletions(-)

 [patch 04/10] stop listening on dbusserver sockets when reaching
 max_incomplete_connections

This addresses the parts of CVE-2014-3639 not already addressed by
reducing the default authentication timeout.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80851
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919
CVE 2014 3477.patch | (download)

bus/activation.c | 27 20 + 7 - 0 !
bus/activation.h | 3 1 + 2 - 0 !
bus/services.c | 5 3 + 2 - 0 !
3 files changed, 24 insertions(+), 11 deletions(-)

 [patch] 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