diff options
author | Simon McVittie <smcv@collabora.com> | 2022-09-30 13:46:31 +0100 |
---|---|---|
committer | Simon McVittie <smcv@collabora.com> | 2022-10-05 10:24:28 +0100 |
commit | 236f16e444e88a984cf12b09225e0f8efa6c5b44 (patch) | |
tree | c9b23b3eecea9da22c173536b95f701c63caa94d /dbus | |
parent | 3ef342410a1cefe3d0bfaf46279c6517f4b44a26 (diff) | |
download | dbus-236f16e444e88a984cf12b09225e0f8efa6c5b44.tar.gz |
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>
Diffstat (limited to 'dbus')
-rw-r--r-- | dbus/dbus-marshal-byteswap.c | 6 |
1 files changed, 1 insertions, 5 deletions
diff --git a/dbus/dbus-marshal-byteswap.c b/dbus/dbus-marshal-byteswap.c index e9de6f02..9dd1246f 100644 --- a/dbus/dbus-marshal-byteswap.c +++ b/dbus/dbus-marshal-byteswap.c @@ -62,6 +62,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 *) (void *) p) = @@ -192,11 +193,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; |