import dbus-1.12.8-10.el8_2

.dbus.metadata

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

.gitignore

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

SOURCES/00-start-message-bus.sh

@@ -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

SOURCES/0001-tools-Use-Python3-for-GetAllMatchRules.patch

@@ -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
+

SOURCES/dbus-1.12.8-fix-CVE-2019-12749.patch

@@ -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
+

SOURCES/dbus-1.12.8-fix-CVE-2020-12049.patch

@@ -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
+