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 filePatch | File delta | Description |
---|---|---|
00_dbus quiesce startup errors.patch | (download) |
bus/config-parser.c |
14 12 + 2 - 0 ! |
--- |
01_no fatal warnings.patch | (download) |
dbus/dbus-internals.c |
2 1 + 1 - 0 ! |
--- |
10_dbus 1.0.1 generate xml docs.patch | (download) |
Doxyfile.in |
2 1 + 1 - 0 ! |
--- |
11 589662 reload kqueue.patch | (download) |
bus/dir-watch-kqueue.c |
2 1 + 1 - 0 ! |
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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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 ! |
[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> |