[PATCH] gnu: dbus: Fix CVE-2019-12749.

DoneSubmitted by Marius Bakke.
2 participants
  • Ludovic Courtès
  • Marius Bakke
Marius Bakke wrote on 15 Jun 2019 13:57
(address . guix-patches@gnu.org)
* gnu/packages/patches/dbus-CVE-2019-12749.patch: New file.* gnu/local.mk (dist_patch_DATA): Adjust accordingly.* gnu/packages/glib.scm (dbus)[replacement]: New field.(dbus/fixed): New variable.--- gnu/local.mk | 1 + gnu/packages/glib.scm | 9 ++ .../patches/dbus-CVE-2019-12749.patch | 116 ++++++++++++++++++ 3 files changed, 126 insertions(+) create mode 100644 gnu/packages/patches/dbus-CVE-2019-12749.patch
Toggle diff (163 lines)diff --git a/gnu/local.mk b/gnu/local.mkindex 5b6dd31b11..f4331f8a95 100644--- a/gnu/local.mk+++ b/gnu/local.mk@@ -740,6 +740,7 @@ dist_patch_DATA = \ %D%/packages/patches/cursynth-wave-rand.patch \ %D%/packages/patches/cvs-2017-12836.patch \ %D%/packages/patches/dbus-helper-search-path.patch \+ %D%/packages/patches/dbus-CVE-2019-12749.patch \ %D%/packages/patches/dealii-mpi-deprecations.patch \ %D%/packages/patches/deja-dup-use-ref-keyword-for-iter.patch \ %D%/packages/patches/dfu-programmer-fix-libusb.patch \diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scmindex 7af7c86853..d75b963794 100644--- a/gnu/packages/glib.scm+++ b/gnu/packages/glib.scm@@ -80,6 +80,7 @@ (package (name "dbus") (version "1.12.12")+ (replacement dbus/fixed) (source (origin (method url-fetch) (uri (string-append@@ -146,6 +147,14 @@ or through unencrypted TCP/IP suitable for use behind a firewall with shared NFS home directories.") (license license:gpl2+))) ; or Academic Free License 2.1 +(define dbus/fixed+ (package+ (inherit dbus)+ (source (origin+ (inherit (package-source dbus))+ (patches (append (search-patches "dbus-CVE-2019-12749.patch")+ (origin-patches (package-source dbus))))))))+ (define glib (package (name "glib")diff --git a/gnu/packages/patches/dbus-CVE-2019-12749.patch b/gnu/packages/patches/dbus-CVE-2019-12749.patchnew file mode 100644index 0000000000..12106f4589--- /dev/null+++ b/gnu/packages/patches/dbus-CVE-2019-12749.patch@@ -0,0 +1,116 @@+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.22.0
Ludovic Courtès wrote on 18 Jun 2019 16:54
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 36224@debbugs.gnu.org)
Hi Marius,
Marius Bakke <mbakke@fastmail.com> skribis:
Toggle quote (5 lines)> * gnu/packages/patches/dbus-CVE-2019-12749.patch: New file.> * gnu/local.mk (dist_patch_DATA): Adjust accordingly.> * gnu/packages/glib.scm (dbus)[replacement]: New field.> (dbus/fixed): New variable.
LGTM. Thanks for addressing it!
Ludovic Courtès wrote on 2 Jul 2019 17:55
control message for bug #36224
(address . control@debbugs.gnu.org)
tags 36224 fixedclose 36224 quit
Your comment

This issue is archived.

To comment on this conversation send email to 36224@debbugs.gnu.org