summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon McVittie <smcv@collabora.com>2022-09-30 13:46:31 +0100
committerUnsung Lee <unsung.lee@samsung.com>2023-02-17 15:35:30 +0900
commit9aca6d45fb390318a8795e6c965f07143d051068 (patch)
tree31bb767adf47835d0229fe51220b9a123fad2c4d
parent15b41b7b4c8f6c940ed25dc56f920b988c8065b6 (diff)
downloaddbus-9aca6d45fb390318a8795e6c965f07143d051068.tar.gz
dbus-9aca6d45fb390318a8795e6c965f07143d051068.tar.bz2
dbus-9aca6d45fb390318a8795e6c965f07143d051068.zip
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) Signed-off-by: Unsung Lee <unsung.lee@samsung.com> Change-Id: Ib67fd7a9ba07cadbd1d223c6596a399c2ae94553
-rw-r--r--dbus/dbus-marshal-byteswap.c6
1 files changed, 1 insertions, 5 deletions
diff --git a/dbus/dbus-marshal-byteswap.c b/dbus/dbus-marshal-byteswap.c
index 27695aaf..7104e9c6 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;