74 lines
3.3 KiB
Diff
74 lines
3.3 KiB
Diff
|
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
|
||
|
|
|