Package: dbus / 1.2.24-4+squeeze2

Metadata

Package Version Patches format
dbus 1.2.24-4+squeeze2 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>