D-Bus daemon endianness issue

[Alp Toker]

The libdbus daemon seems to send malformed messages claiming to be 
big-endian but containing little-endian values under certain conditions.

This pseudo-code triggers the bug on my x86 system when the client 
library is made to send big-endian messages:

   Connection bus = Bus.Session;
   bus.AddMatch ("type='method_call'");
   Message msg = bus.ReadMessage ();

The fixed part of the message header returned by dbus-daemon at 
ReadMessage () is:

"B\1\0\1\27\0\0\0\2\0\0\0\217\0\0\0"

You can see the big-endian flag at the start yet the uint values are 
clearly little-endian.

The array of variants keyed by field codes in the header is the same:

"\1\1o\0\25\0\0\0/org/freedesktop/DBus\0\0\0\2\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0\3\1s\0\10\0\0\0AddMatch\0\0\0\0\0\0\0\0\6\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0\10\1g\0\1s\0\0\7\1s\0\6\0\0\0:1.196\0\0"

For the benefit of those who don't hack D-Bus, this is the managed 
(http://www.ndesk.org/DBusSharp) form of this serialized structure:

   struct Header
   {
     public EndianFlag Endianness;
     public MessageType MessageType;
     public HeaderFlag Flags;
     public byte MajorVersion;
     public uint Length;
     public uint Serial;
     public IDictionary<FieldCode,object> Fields;
   }

The message body is also little-endian:

"\22\0\0\0type=\'method_call\'\0"

Adding match rules for signals works fine though, and the signal 
messages are provided in the endianness in which they were sent. This is 
probably the expected behaviour for the currently broken method_call case.

This is crippling for any dbus-monitor tool that uses network byte order 
on a little-endian system. It may also affect interoperability between 
platforms.

It may be possible not only to crash others' connections to the bus in 
some configurations, but also to use a carefully crafted sequence of 
messages to place applications in an unexpected state. Constructing a 
message with a spoofed body length large enough to cause the client 
library to read the content of the following message comes to mind. The 
content of the following message could be parsed as part of the original 
message given a byte array signature, providing a way to obtain the full 
headers and bodies of arbitrary messages from, say, a forwarding daemon.