orion / rpms / dbus

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