Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 6 Oct 2022 19:26:35 +0100
From: Simon McVittie <>
Cc: Demi Marie Obenour <>
Subject: Re: dbus denial of service: CVE-2022-42010, -42011,

On Thu, 06 Oct 2022 at 13:00:03 -0400, Demi Marie Obenour wrote:
> On Thu, Oct 06, 2022 at 04:40:10PM +0100, Simon McVittie wrote:
> > CVE-2022-42012 (which involves a
> > message that is odd but technically valid)
> Should different-endian messages over AF_UNIX sockets just be rejected
> outright?

Probably not. I believe that would regress the ability to interoperate
with dbus-java, which can receive either endianness but always sends
big-endian messages.

It could also be annoying for proxying/forwarding tools like systemd's
systemd-stdio-bridge, which is used to forward D-Bus connections to a
remote bus's AF_UNIX socket via ssh (obviously out-of-band fd-passing
like the feature that triggers CVE-2022-42012 can't work that way, but
most of D-Bus is in-band), depending on whether systemd-stdio-bridge
deserializes and reserializes messages or whether it just streams data
without understanding its internal structure. There's nothing to stop
you from using a client on a little-endian PC to debug a service on a
big-endian embedded device over a ssh tunnel using systemd-stdio-bridge
or even socat, but in that scenario, each end of the connection will
be sending messages in its own endianness and receiving messages in the
other endianness.

If I was designing D-Bus today, I'd probably pick a canonical endianness
and stick to it (more like GVariant, parts of which are always LE),
but it's too late for that: the "wire protocol" has been stable since
about 2006, which was before I got involved.


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.