dbus-marshal-byteswap: Byte-swap Unix fd indexes if needed 05/294505/1 accepted/tizen_6.0_unified tizen_6.0 accepted/tizen/6.0/unified/20230626.074931
authorSimon McVittie <smcv@collabora.com>
Fri, 30 Sep 2022 12:46:31 +0000 (13:46 +0100)
committerChanwoo Choi <cw00.choi@samsung.com>
Tue, 20 Jun 2023 08:29:46 +0000 (17:29 +0900)
commit8b75da368bd869301efc17551c597aa372d2bf6f
tree7e2e262a5d3f8d3a5f68e532b2539f6c63b1324c
parent590b03852136e9c9a4cd87470ca93a5ca945c841
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)
Signed-off-by: Unsung Lee <unsung.lee@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Change-Id: I9a206ed20bccb1265a730bab1ca625d5734e4f80
dbus/dbus-marshal-byteswap.c