rpms
/
dbus
20
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

import dbus-1.12.8-24.el8

Browse Source
c8 imports/c8/dbus-1.12.8-24.el8
CentOS Sources 2 years ago committed by MSVSphere Packaging Team
commit 26663feafa
15 changed files with 2213 additions and 0 deletions
Show Stats Download Patch File Download Diff File

1
.dbus.metadata
Unescape View File

@ -0,0 +1 @@
8e50e46796e8297eaa633da3a61cdc79a500e34a SOURCES/dbus-1.12.8.tar.gz

1
.gitignore vendored
Unescape View File

@ -0,0 +1 @@
SOURCES/dbus-1.12.8.tar.gz

14
SOURCES/00-start-message-bus.sh
Unescape View File

@ -0,0 +1,14 @@
#!/bin/sh
# Copyright (C) 2008 Red Hat, Inc.
#
# All rights reserved. This copyrighted material is made available to anyone
# wishing to use, modify, copy, or redistribute it subject to the terms and
# conditions of the GNU General Public License version 2.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
eval `dbus-launch --sh-syntax --exit-with-session`
fi

22
SOURCES/0001-tools-Use-Python3-for-GetAllMatchRules.patch
Unescape View File

@ -0,0 +1,22 @@
From 59ddde9e1ed5de03b060ff3ce27e35509707dff2 Mon Sep 17 00:00:00 2001
From: Colin Walters <walters@verbum.org>
Date: Tue, 31 Jul 2018 12:33:59 -0400
Subject: [PATCH] tools: Use Python3 for GetAllMatchRules
---
tools/GetAllMatchRules.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/GetAllMatchRules.py b/tools/GetAllMatchRules.py
index 6a7e4cd9..f7e340d6 100755
--- a/tools/GetAllMatchRules.py
+++ b/tools/GetAllMatchRules.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/python3
import sys
import argparse
--
2.17.1

119
SOURCES/dbus-1.12.8-fix-CVE-2019-12749.patch
Unescape View File

@ -0,0 +1,119 @@
From 47b1a4c41004bf494b87370987b222c934b19016 Mon Sep 17 00:00:00 2001
From: Simon McVittie <smcv@collabora.com>
Date: Thu, 30 May 2019 12:53:03 +0100
Subject: [PATCH] auth: Reject DBUS_COOKIE_SHA1 for users other than the server
owner
The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
of a shared home directory by having the server write a secret "cookie"
into a .dbus-keyrings subdirectory of the desired identity's home
directory with 0700 permissions, and having the client prove that it can
read the cookie. This never actually worked for non-malicious clients in
the case where server uid != client uid (unless the server and client
both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
Unix uid 0) because an unprivileged server would fail to write out the
cookie, and an unprivileged client would be unable to read the resulting
file owned by the server.
Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
is owned by the uid of the server (a side-effect of a check added to
harden our use of XDG_RUNTIME_DIR), further ruling out successful use
by a non-malicious client with a uid differing from the server's.
Joe Vennix of Apple Information Security discovered that the
implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link
attack: a malicious client with write access to its own home directory
could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to
read and write in unintended locations. In the worst case this could
result in the DBusServer reusing a cookie that is known to the
malicious client, and treating that cookie as evidence that a subsequent
client connection came from an attacker-chosen uid, allowing
authentication bypass.
This is mitigated by the fact that by default, the well-known system
dbus-daemon (since 2003) and the well-known session dbus-daemon (in
stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL
authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1
at an early stage, before manipulating cookies. As a result, this
vulnerability only applies to:
* system or session dbus-daemons with non-standard configuration
* third-party dbus-daemon invocations such as at-spi2-core (although
in practice at-spi2-core also only accepts EXTERNAL by default)
* third-party uses of DBusServer such as the one in Upstart
Avoiding symlink attacks in a portable way is difficult, because APIs
like openat() and Linux /proc/self/fd are not universally available.
However, because DBUS_COOKIE_SHA1 already doesn't work in practice for
a non-matching uid, we can solve this vulnerability in an easier way
without regressions, by rejecting it early (before looking at
~/.dbus-keyrings) whenever the requested identity doesn't match the
identity of the process hosting the DBusServer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/269
Closes: CVE-2019-12749
---
dbus/dbus-auth.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/dbus/dbus-auth.c b/dbus/dbus-auth.c
index 37d8d4c9..7390a9d5 100644
--- a/dbus/dbus-auth.c
+++ b/dbus/dbus-auth.c
@@ -529,6 +529,7 @@ sha1_handle_first_client_response (DBusAuth *auth,
DBusString tmp2;
dbus_bool_t retval = FALSE;
DBusError error = DBUS_ERROR_INIT;
+ DBusCredentials *myself = NULL;
_dbus_string_set_length (&auth->challenge, 0);
@@ -565,6 +566,34 @@ sha1_handle_first_client_response (DBusAuth *auth,
return FALSE;
}
+ myself = _dbus_credentials_new_from_current_process ();
+
+ if (myself == NULL)
+ goto out;
+
+ if (!_dbus_credentials_same_user (myself, auth->desired_identity))
+ {
+ /*
+ * DBUS_COOKIE_SHA1 is not suitable for authenticating that the
+ * client is anyone other than the user owning the process
+ * containing the DBusServer: we probably aren't allowed to write
+ * to other users' home directories. Even if we can (for example
+ * uid 0 on traditional Unix or CAP_DAC_OVERRIDE on Linux), we
+ * must not, because the other user controls their home directory,
+ * and could carry out symlink attacks to make us read from or
+ * write to unintended locations. It's difficult to avoid symlink
+ * attacks in a portable way, so we just don't try. This isn't a
+ * regression, because DBUS_COOKIE_SHA1 never worked for other
+ * users anyway.
+ */
+ _dbus_verbose ("%s: client tried to authenticate as \"%s\", "
+ "but that doesn't match this process",
+ DBUS_AUTH_NAME (auth),
+ _dbus_string_get_const_data (data));
+ retval = send_rejected (auth);
+ goto out;
+ }
+
/* we cache the keyring for speed, so here we drop it if it's the
* wrong one. FIXME caching the keyring here is useless since we use
* a different DBusAuth for every connection.
@@ -679,6 +708,9 @@ sha1_handle_first_client_response (DBusAuth *auth,
_dbus_string_zero (&tmp2);
_dbus_string_free (&tmp2);
+ if (myself != NULL)
+ _dbus_credentials_unref (myself);
+
return retval;
}
--
2.21.0

74
SOURCES/dbus-1.12.8-fix-CVE-2020-12049.patch
Unescape View File

@ -0,0 +1,74 @@
From 872b085f12f56da25a2dbd9bd0b2dff31d5aea63 Mon Sep 17 00:00:00 2001
From: Simon McVittie <smcv@collabora.com>
Date: Thu, 16 Apr 2020 14:45:11 +0100
Subject: [PATCH] sysdeps-unix: On MSG_CTRUNC, close the fds we did receive
MSG_CTRUNC indicates that we have received fewer fds that we should
have done because the buffer was too small, but we were treating it
as though it indicated that we received *no* fds. If we received any,
we still have to make sure we close them, otherwise they will be leaked.
On the system bus, if an attacker can induce us to leak fds in this
way, that's a local denial of service via resource exhaustion.
Reported-by: Kevin Backhouse, GitHub Security Lab
Fixes: dbus#294
Fixes: CVE-2020-12049
Fixes: GHSL-2020-057
---
dbus/dbus-sysdeps-unix.c | 32 ++++++++++++++++++++------------
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/dbus/dbus-sysdeps-unix.c b/dbus/dbus-sysdeps-unix.c
index b5fc24663..b176dae1a 100644
--- a/dbus/dbus-sysdeps-unix.c
+++ b/dbus/dbus-sysdeps-unix.c
@@ -435,18 +435,6 @@ _dbus_read_socket_with_unix_fds (DBusSocket fd,
struct cmsghdr *cm;
dbus_bool_t found = FALSE;
- if (m.msg_flags & MSG_CTRUNC)
- {
- /* Hmm, apparently the control data was truncated. The bad
- thing is that we might have completely lost a couple of fds
- without chance to recover them. Hence let's treat this as a
- serious error. */
-
- errno = ENOSPC;
- _dbus_string_set_length (buffer, start);
- return -1;
- }
-
for (cm = CMSG_FIRSTHDR(&m); cm; cm = CMSG_NXTHDR(&m, cm))
if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_RIGHTS)
{
@@ -501,6 +489,26 @@ _dbus_read_socket_with_unix_fds (DBusSocket fd,
if (!found)
*n_fds = 0;
+ if (m.msg_flags & MSG_CTRUNC)
+ {
+ unsigned int i;
+
+ /* Hmm, apparently the control data was truncated. The bad
+ thing is that we might have completely lost a couple of fds
+ without chance to recover them. Hence let's treat this as a
+ serious error. */
+
+ /* We still need to close whatever fds we *did* receive,
+ * otherwise they'll never get closed. (CVE-2020-12049) */
+ for (i = 0; i < *n_fds; i++)
+ close (fds[i]);
+
+ *n_fds = 0;
+ errno = ENOSPC;
+ _dbus_string_set_length (buffer, start);
+ return -1;
+ }
+
/* put length back (doesn't actually realloc) */
_dbus_string_set_length (buffer, start + bytes_read);
--
GitLab

201
SOURCES/dbus-1.12.8-fix-fd-limit-change.patch
Unescape View File

@ -0,0 +1,201 @@
From 94bacc6955e563a7e698e53151a75323279a9f45 Mon Sep 17 00:00:00 2001
From: Simon McVittie <smcv@collabora.com>
Date: Mon, 11 Mar 2019 09:03:39 +0000
Subject: [PATCH] bus: Try to raise soft fd limit to match hard limit
Linux systems have traditionally set the soft limit to 1024 and the hard
limit to 4096. Recent versions of systemd keep the soft fd limit at
1024 to avoid breaking programs that still use select(), but raise the
hard limit to 512*1024, while in recent Debian versions a complicated
interaction between components gives a soft limit of 1024 and a hard
limit of 1024*1024. If we can, we might as well elevate our soft limit
to match the hard limit, minimizing the chance that we will run out of
file descriptor slots.
Unlike the previous code to raise the hard and soft limits to at least
65536, we do this even if we don't have privileges: privileges are
unnecessary to raise the soft limit up to the hard limit.
If we *do* have privileges, we also continue to raise the hard and soft
limits to at least 65536 if they weren't already that high, making
it harder to carry out a denial of service attack on the system bus on
systems that use the traditional limit (CVE-2014-7824).
As was previously the case on the system bus, we'll drop the limits back
to our initial limits before we execute a subprocess for traditional
(non-systemd) activation, if enabled.
systemd activation doesn't involve us starting subprocesses at all,
so in both cases activated services will still inherit the same limits
they did previously.
This change also fixes a bug when the hard limit is very large but
the soft limit is not, for example seen as a regression when upgrading
to systemd >= 240 (Debian #928877). In such environments, dbus-daemon
would previously have changed its fd limit to 64K soft/64K hard. Because
this hard limit is less than its original hard limit, it was unable to
restore its original hard limit as intended when carrying out traditional
activation, leaving activated subprocesses with unintended limits (while
logging a warning).
Reviewed-by: Lennart Poettering <lennart@poettering.net>
[smcv: Correct a comment based on Lennart's review, reword commit message]
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7eacbfece70f16bb54d0f3ac51f87ae398759ef5)
[smcv: Mention that this also fixes Debian #928877]
---
bus/bus.c | 8 ++---
dbus/dbus-sysdeps-util-unix.c | 64 +++++++++++++++++++++--------------
dbus/dbus-sysdeps-util-win.c | 3 +-
dbus/dbus-sysdeps.h | 3 +-
4 files changed, 44 insertions(+), 34 deletions(-)
diff --git a/bus/bus.c b/bus/bus.c
index 30ce4e10..2ad8e789 100644
--- a/bus/bus.c
+++ b/bus/bus.c
@@ -693,11 +693,11 @@ raise_file_descriptor_limit (BusContext *context)
/* We used to compute a suitable rlimit based on the configured number
* of connections, but that breaks down as soon as we allow fd-passing,
* because each connection is allowed to pass 64 fds to us, and if
- * they all did, we'd hit kernel limits. We now hard-code 64k as a
- * good limit, like systemd does: that's enough to avoid DoS from
- * anything short of multiple uids conspiring against us.
+ * they all did, we'd hit kernel limits. We now hard-code a good
+ * limit that is enough to avoid DoS from anything short of multiple
+ * uids conspiring against us, much like systemd does.
*/
- if (!_dbus_rlimit_raise_fd_limit_if_privileged (65536, &error))
+ if (!_dbus_rlimit_raise_fd_limit (&error))
{
bus_context_log (context, DBUS_SYSTEM_LOG_WARNING,
"%s: %s", error.name, error.message);
diff --git a/dbus/dbus-sysdeps-util-unix.c b/dbus/dbus-sysdeps-util-unix.c
index 2be5b779..7c4c3604 100644
--- a/dbus/dbus-sysdeps-util-unix.c
+++ b/dbus/dbus-sysdeps-util-unix.c
@@ -406,23 +406,15 @@ _dbus_rlimit_save_fd_limit (DBusError *error)
return self;
}
+/* Enough fds that we shouldn't run out, even if several uids work
+ * together to carry out a denial-of-service attack. This happens to be
+ * the same number that systemd < 234 would normally use. */
+#define ENOUGH_FDS 65536
+
dbus_bool_t
-_dbus_rlimit_raise_fd_limit_if_privileged (unsigned int desired,
- DBusError *error)
+_dbus_rlimit_raise_fd_limit (DBusError *error)
{
- struct rlimit lim;
-
- /* No point to doing this practically speaking
- * if we're not uid 0. We expect the system
- * bus to use this before we change UID, and
- * the session bus takes the Linux default,
- * currently 1024 for cur and 4096 for max.
- */
- if (getuid () != 0)
- {
- /* not an error, we're probably the session bus */
- return TRUE;
- }
+ struct rlimit old, lim;
if (getrlimit (RLIMIT_NOFILE, &lim) < 0)
{
@@ -431,22 +423,43 @@ _dbus_rlimit_raise_fd_limit_if_privileged (unsigned int desired,
return FALSE;
}
- if (lim.rlim_cur == RLIM_INFINITY || lim.rlim_cur >= desired)
+ old = lim;
+
+ if (getuid () == 0)
{
- /* not an error, everything is fine */
- return TRUE;
+ /* We are privileged, so raise the soft limit to at least
+ * ENOUGH_FDS, and the hard limit to at least the desired soft
+ * limit. This assumes we can exercise CAP_SYS_RESOURCE on Linux,
+ * or other OSs' equivalents. */
+ if (lim.rlim_cur != RLIM_INFINITY &&
+ lim.rlim_cur < ENOUGH_FDS)
+ lim.rlim_cur = ENOUGH_FDS;
+
+ if (lim.rlim_max != RLIM_INFINITY &&
+ lim.rlim_max < lim.rlim_cur)
+ lim.rlim_max = lim.rlim_cur;
}
- /* Ignore "maximum limit", assume we have the "superuser"
- * privileges. On Linux this is CAP_SYS_RESOURCE.
- */
- lim.rlim_cur = lim.rlim_max = desired;
+ /* Raise the soft limit to match the hard limit, which we can do even
+ * if we are unprivileged. In particular, systemd >= 240 will normally
+ * set rlim_cur to 1024 and rlim_max to 512*1024, recent Debian
+ * versions end up setting rlim_cur to 1024 and rlim_max to 1024*1024,
+ * and older and non-systemd Linux systems would typically set rlim_cur
+ * to 1024 and rlim_max to 4096. */
+ if (lim.rlim_max == RLIM_INFINITY || lim.rlim_cur < lim.rlim_max)
+ lim.rlim_cur = lim.rlim_max;
+
+ /* Early-return if there is nothing to do. */
+ if (lim.rlim_max == old.rlim_max &&
+ lim.rlim_cur == old.rlim_cur)
+ return TRUE;
if (setrlimit (RLIMIT_NOFILE, &lim) < 0)
{
dbus_set_error (error, _dbus_error_from_errno (errno),
- "Failed to set fd limit to %u: %s",
- desired, _dbus_strerror (errno));
+ "Failed to set fd limit to %lu: %s",
+ (unsigned long) lim.rlim_cur,
+ _dbus_strerror (errno));
return FALSE;
}
@@ -485,8 +498,7 @@ _dbus_rlimit_save_fd_limit (DBusError *error)
}
dbus_bool_t
-_dbus_rlimit_raise_fd_limit_if_privileged (unsigned int desired,
- DBusError *error)
+_dbus_rlimit_raise_fd_limit (DBusError *error)
{
fd_limit_not_supported (error);
return FALSE;
diff --git a/dbus/dbus-sysdeps-util-win.c b/dbus/dbus-sysdeps-util-win.c
index 1ef4ae6c..1c1d9f7d 100644
--- a/dbus/dbus-sysdeps-util-win.c
+++ b/dbus/dbus-sysdeps-util-win.c
@@ -273,8 +273,7 @@ _dbus_rlimit_save_fd_limit (DBusError *error)
}
dbus_bool_t
-_dbus_rlimit_raise_fd_limit_if_privileged (unsigned int desired,
- DBusError *error)
+_dbus_rlimit_raise_fd_limit (DBusError *error)
{
fd_limit_not_supported (error);
return FALSE;
diff --git a/dbus/dbus-sysdeps.h b/dbus/dbus-sysdeps.h
index ef786ecc..0b9d7696 100644
--- a/dbus/dbus-sysdeps.h
+++ b/dbus/dbus-sysdeps.h
@@ -698,8 +698,7 @@ dbus_bool_t _dbus_replace_install_prefix (DBusString *path);
typedef struct DBusRLimit DBusRLimit;
DBusRLimit *_dbus_rlimit_save_fd_limit (DBusError *error);
-dbus_bool_t _dbus_rlimit_raise_fd_limit_if_privileged (unsigned int desired,
- DBusError *error);
+dbus_bool_t _dbus_rlimit_raise_fd_limit (DBusError *error);
dbus_bool_t _dbus_rlimit_restore_fd_limit (DBusRLimit *saved,
DBusError *error);
void _dbus_rlimit_free (DBusRLimit *lim);
--
GitLab

116
SOURCES/dbus-1.20.8-CVE-2022-42010.patch
Unescape View File

@ -0,0 +1,116 @@
From 8f382ee405ec68850866298ba0574f12e261a6fa Mon Sep 17 00:00:00 2001
From: Simon McVittie <smcv@collabora.com>
Date: Tue, 13 Sep 2022 15:10:22 +0100
Subject: [PATCH] dbus-marshal-validate: Check brackets in signature nest
correctly
In debug builds with assertions enabled, a signature with incorrectly
nested `()` and `{}`, for example `a{i(u}` or `(a{ii)}`, could result
in an assertion failure.
In production builds without assertions enabled, a signature with
incorrectly nested `()` and `{}` could potentially result in a crash
or incorrect message parsing, although we do not have a concrete example
of either of these failure modes.
Thanks: Evgeny Vereshchagin
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/418
Resolves: CVE-2022-42010
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9d07424e9011e3bbe535e83043d335f3093d2916)
(cherry picked from commit 3e53a785dee8d1432156188a2c4260e4cbc78c4d)
---
dbus/dbus-marshal-validate.c | 38 +++++++++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/dbus/dbus-marshal-validate.c b/dbus/dbus-marshal-validate.c
index 4d492f3f3..ae68414dd 100644
--- a/dbus/dbus-marshal-validate.c
+++ b/dbus/dbus-marshal-validate.c
@@ -62,6 +62,8 @@ _dbus_validate_signature_with_reason (const DBusString *type_str,
int element_count;
DBusList *element_count_stack;
+ char opened_brackets[DBUS_MAXIMUM_TYPE_RECURSION_DEPTH * 2 + 1] = { '\0' };
+ char last_bracket;
result = DBUS_VALID;
element_count_stack = NULL;
@@ -93,6 +95,10 @@ _dbus_validate_signature_with_reason (const DBusString *type_str,
while (p != end)
{
+ _dbus_assert (struct_depth + dict_entry_depth >= 0);
+ _dbus_assert (struct_depth + dict_entry_depth < _DBUS_N_ELEMENTS (opened_brackets));
+ _dbus_assert (opened_brackets[struct_depth + dict_entry_depth] == '\0');
+
switch (*p)
{
case DBUS_TYPE_BYTE:
@@ -136,6 +142,10 @@ _dbus_validate_signature_with_reason (const DBusString *type_str,
goto out;
}
+ _dbus_assert (struct_depth + dict_entry_depth >= 1);
+ _dbus_assert (struct_depth + dict_entry_depth < _DBUS_N_ELEMENTS (opened_brackets));
+ _dbus_assert (opened_brackets[struct_depth + dict_entry_depth - 1] == '\0');
+ opened_brackets[struct_depth + dict_entry_depth - 1] = DBUS_STRUCT_BEGIN_CHAR;
break;
case DBUS_STRUCT_END_CHAR:
@@ -151,9 +161,20 @@ _dbus_validate_signature_with_reason (const DBusString *type_str,
goto out;
}
+ _dbus_assert (struct_depth + dict_entry_depth >= 1);
+ _dbus_assert (struct_depth + dict_entry_depth < _DBUS_N_ELEMENTS (opened_brackets));
+ last_bracket = opened_brackets[struct_depth + dict_entry_depth - 1];
+
+ if (last_bracket != DBUS_STRUCT_BEGIN_CHAR)
+ {
+ result = DBUS_INVALID_STRUCT_ENDED_BUT_NOT_STARTED;
+ goto out;
+ }
+
_dbus_list_pop_last (&element_count_stack);
struct_depth -= 1;
+ opened_brackets[struct_depth + dict_entry_depth] = '\0';
break;
case DBUS_DICT_ENTRY_BEGIN_CHAR:
@@ -178,6 +199,10 @@ _dbus_validate_signature_with_reason (const DBusString *type_str,
goto out;
}
+ _dbus_assert (struct_depth + dict_entry_depth >= 1);
+ _dbus_assert (struct_depth + dict_entry_depth < _DBUS_N_ELEMENTS (opened_brackets));
+ _dbus_assert (opened_brackets[struct_depth + dict_entry_depth - 1] == '\0');
+ opened_brackets[struct_depth + dict_entry_depth - 1] = DBUS_DICT_ENTRY_BEGIN_CHAR;
break;
case DBUS_DICT_ENTRY_END_CHAR:
@@ -186,8 +211,19 @@ _dbus_validate_signature_with_reason (const DBusString *type_str,
result = DBUS_INVALID_DICT_ENTRY_ENDED_BUT_NOT_STARTED;
goto out;
}
-
+
+ _dbus_assert (struct_depth + dict_entry_depth >= 1);
+ _dbus_assert (struct_depth + dict_entry_depth < _DBUS_N_ELEMENTS (opened_brackets));
+ last_bracket = opened_brackets[struct_depth + dict_entry_depth - 1];
+
+ if (last_bracket != DBUS_DICT_ENTRY_BEGIN_CHAR)
+ {
+ result = DBUS_INVALID_DICT_ENTRY_ENDED_BUT_NOT_STARTED;
+ goto out;
+ }
+
dict_entry_depth -= 1;
+ opened_brackets[struct_depth + dict_entry_depth] = '\0';
element_count =
_DBUS_POINTER_TO_INT (_dbus_list_pop_last (&element_count_stack));
--
GitLab

57
SOURCES/dbus-1.20.8-CVE-2022-42011.patch
Unescape View File

@ -0,0 +1,57 @@
From 3b8a7aff228770f4f7b478db606b10cceacea875 Mon Sep 17 00:00:00 2001
From: Simon McVittie <smcv@collabora.com>
Date: Mon, 12 Sep 2022 13:14:18 +0100
Subject: [PATCH] dbus-marshal-validate: Validate length of arrays of
fixed-length items
This fast-path previously did not check that the array was made up
of an integer number of items. This could lead to assertion failures
and out-of-bounds accesses during subsequent message processing (which
assumes that the message has already been validated), particularly after
the addition of _dbus_header_remove_unknown_fields(), which makes it
more likely that dbus-daemon will apply non-trivial edits to messages.
Thanks: Evgeny Vereshchagin
Fixes: e61f13cf "Bug 18064 - more efficient validation for fixed-size type arrays"
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/413
Resolves: CVE-2022-42011
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 079bbf16186e87fb0157adf8951f19864bc2ed69)
(cherry picked from commit b9e6a7523085a2cfceaffca7ba1ab4251f12a984)
---
dbus/dbus-marshal-validate.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/dbus/dbus-marshal-validate.c b/dbus/dbus-marshal-validate.c
index ae68414dd..7d0d6cf72 100644
--- a/dbus/dbus-marshal-validate.c
+++ b/dbus/dbus-marshal-validate.c
@@ -503,13 +503,24 @@ validate_body_helper (DBusTypeReader *reader,
*/
if (dbus_type_is_fixed (array_elem_type))
{
+ /* Note that fixed-size types all have sizes equal to
+ * their alignments, so this is really the item size. */
+ alignment = _dbus_type_get_alignment (array_elem_type);
+ _dbus_assert (alignment == 1 || alignment == 2 ||
+ alignment == 4 || alignment == 8);
+
+ /* Because the alignment is a power of 2, this is
+ * equivalent to: (claimed_len % alignment) != 0,
+ * but avoids slower integer division */
+ if ((claimed_len & (alignment - 1)) != 0)
+ return DBUS_INVALID_ARRAY_LENGTH_INCORRECT;
+
/* bools need to be handled differently, because they can
* have an invalid value
*/
if (array_elem_type == DBUS_TYPE_BOOLEAN)
{
dbus_uint32_t v;
- alignment = _dbus_type_get_alignment (array_elem_type);
while (p < array_end)
{
--
GitLab

73
SOURCES/dbus-1.20.8-CVE-2022-42012.patch
Unescape View File

@ -0,0 +1,73 @@
From 51a5bbf9074855b0f4a353ed309938b196c13525 Mon Sep 17 00:00:00 2001
From: Simon McVittie <smcv@collabora.com>
Date: Fri, 30 Sep 2022 13:46:31 +0100
Subject: [PATCH] dbus-marshal-byteswap: Byte-swap Unix fd indexes if needed
When a D-Bus message includes attached file descriptors, the body of the
message contains unsigned 32-bit indexes pointing into an out-of-band
array of file descriptors. Some D-Bus APIs like GLib's GDBus refer to
these indexes as "handles" for the associated fds (not to be confused
with a Windows HANDLE, which is a kernel object).
The assertion message removed by this commit is arguably correct up to
a point: fd-passing is only reasonable on a local machine, and no known
operating system allows processes of differing endianness even on a
multi-endian ARM or PowerPC CPU, so it makes little sense for the sender
to specify a byte-order that differs from the byte-order of the recipient.
However, this doesn't account for the fact that a malicious sender
doesn't have to restrict itself to only doing things that make sense.
On a system with untrusted local users, a message sender could crash
the system dbus-daemon (a denial of service) by sending a message in
the opposite endianness that contains handles to file descriptors.
Before this commit, if assertions are enabled, attempting to byteswap
a fd index would cleanly crash the message recipient with an assertion
failure. If assertions are disabled, attempting to byteswap a fd index
would silently do nothing without advancing the pointer p, causing the
message's type and the pointer into its contents to go out of sync, which
can result in a subsequent crash (the crash demonstrated by fuzzing was
a use-after-free, but other failure modes might be possible).
In principle we could resolve this by rejecting wrong-endianness messages
from a local sender, but it's actually simpler and less code to treat
wrong-endianness messages as valid and byteswap them.
Thanks: Evgeny Vereshchagin
Fixes: ba7daa60 "unix-fd: add basic marshalling code for unix fds"
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/417
Resolves: CVE-2022-42012
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 236f16e444e88a984cf12b09225e0f8efa6c5b44)
(cherry picked from commit 3fb065b0752db1e298e4ada52cf4adc414f5e946)
---
dbus/dbus-marshal-byteswap.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/dbus/dbus-marshal-byteswap.c b/dbus/dbus-marshal-byteswap.c
index 27695aafb..7104e9c63 100644
--- a/dbus/dbus-marshal-byteswap.c
+++ b/dbus/dbus-marshal-byteswap.c
@@ -61,6 +61,7 @@ byteswap_body_helper (DBusTypeReader *reader,
case DBUS_TYPE_BOOLEAN:
case DBUS_TYPE_INT32:
case DBUS_TYPE_UINT32:
+ case DBUS_TYPE_UNIX_FD:
{
p = _DBUS_ALIGN_ADDRESS (p, 4);
*((dbus_uint32_t*)p) = DBUS_UINT32_SWAP_LE_BE (*((dbus_uint32_t*)p));
@@ -188,11 +189,6 @@ byteswap_body_helper (DBusTypeReader *reader,
}
break;
- case DBUS_TYPE_UNIX_FD:
- /* fds can only be passed on a local machine, so byte order must always match */
- _dbus_assert_not_reached("attempted to byteswap unix fds which makes no sense");
- break;
-
default:
_dbus_assert_not_reached ("invalid typecode in supposedly-validated signature");
break;
--
GitLab

28
SOURCES/dbus-kill-process-with-session
Unescape View File

@ -0,0 +1,28 @@
#!/bin/bash
# This script ensures the dbus-daemon is killed when the session closes.
# It's used by SSH sessions that have X forwarding (since the X display
# may outlive the session in those cases)
[ $# != 1 ] && exit 1
exec >& /dev/null
MONITOR_READY_FILE=$(mktemp dbus-session-monitor.XXXXXX --tmpdir)
trap 'rm -f "${MONITOR_READY_FILE}"; kill -TERM $1; kill -HUP $(jobs -p)' EXIT
export GVFS_DISABLE_FUSE=1
coproc SESSION_MONITOR (gio monitor -f "/run/systemd/sessions/${XDG_SESSION_ID}" "${MONITOR_READY_FILE}")
# Poll until the gio monitor command is actively monitoring
until
touch "${MONITOR_READY_FILE}"
read -t 0.5 -u ${SESSION_MONITOR[0]}
do
continue
done
# Block until the session is closed
while grep -q ^State=active <(loginctl show-session $XDG_SESSION_ID)
do
read -u ${SESSION_MONITOR[0]}
done

2
SOURCES/dbus-systemd-sysusers.conf
Unescape View File

@ -0,0 +1,2 @@
#Type Name ID GECOS Home directory Shell
u dbus 81 "System Message Bus" - -

10
SOURCES/ssh-x-forwarding.csh
Unescape View File

@ -0,0 +1,10 @@
# DBus session bus over SSH with X11 forwarding
if ( $?SSH_CONNECTION == 0 ) exit
if ( $?DISPLAY == 0 ) exit
if ( $SHLVL > 1 ) exit
setenv GDK_BACKEND x11
eval `dbus-launch --csh-syntax`
if ( $?DBUS_SESSION_BUS_PID == 0 ) exit
setsid -f /usr/libexec/dbus-1/dbus-kill-process-with-session $DBUS_SESSION_BUS_PID

12
SOURCES/ssh-x-forwarding.sh
Unescape View File

@ -0,0 +1,12 @@
# DBus session bus over SSH with X11 forwarding
[ -z "$SSH_CONNECTION" ] && return
[ -z "$DISPLAY" ] && return
[ "${DISPLAY:0:1}" = ":" ] && return
[ "$SHLVL" -ne 1 ] && return
export GDK_BACKEND=x11
eval `dbus-launch --sh-syntax`
[ -z "$DBUS_SESSION_BUS_PID" ] && return
setsid -f /usr/libexec/dbus-1/dbus-kill-process-with-session "$DBUS_SESSION_BUS_PID"

1483
SPECS/dbus.spec
View File

File diff suppressed because it is too large Load Diff
Write Preview
Loading…
Cancel
Save