From 525c2314c56504fb232f9ec7f25cf7dda4d4a1c4 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 ea43ce72..c0b7b903 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