How not to use dbus (in cars or anywhere else)

[rony]

There is one use-case that is quite important in a mixed operating system environment, where one has
Linux, MacOSX and/or Windows PCs in a secured LAN cross-platform deployment, where client/server
apps can be developed easily using DBus as a cross-platform transport of messages. This ability
should remain available, not sure whether it is sensible or possible to use something like SSL to
increase security in such a cross-operating system mix of computers.

---rony

On 25.08.2015 16:23, Simon McVittie wrote:
> (I have bcc'd various people who advocated the addition of the ANONYMOUS
> authentication mechanism to D-Bus, for their feedback on potentially
> removing it from dbus-daemon 1.11.)
>
> On 24/08/15 16:03, Colin Walters wrote:
>> http://illmatics.com/Remote%20Car%20Hacking.pdf
> Indeed; for the attacks described in this paper to work, the platform's
> dbus-daemon has to be set up rather spectacularly wrong.
>
> I am not considering this to be a vulnerability in dbus: it's user error
> of the form "you asked for it, you got it". However, as a piece of
> security hardening, I wonder whether we should be modifying dbus-daemon
> so that it refuses to be set up that badly...
>
>> 1) Exposing the bus over TCP.  I'd recommend having debugging sessions go over ssh.
>> 1a) Exposing the bus over TCP to all interfaces, including an
>> interface for the public internet
> Once I've released D-Bus 1.10 (new stable branch), which has waited too
> long already, I'm somewhat tempted to make dbus-daemon 1.11 abort() if
> asked to listen on anything except unix: or systemd: on Unix platforms.
> 1.9/1.10 already configure the system and session buses to only accept
> EXTERNAL authentication (which can't work over non-AF_UNIX) on Unix
> platforms... but maybe people would be a little more reluctant to do it
> wrong if they had to alter the source code to do so, not just the
> configuration?
>
> I happen to know that QNX (the relevant platform for those attacks
> according to the paper) does support AF_UNIX ... because Matt Fischer at
> Garmin contributed some patches to make it work, fully-featured, with
> fd-passing and everything. This is how embedded vendors should deal with
> things like D-Bus: if the secure way doesn't work on your platform, make
> it work.
>
> On Windows, we have to use TCP because there is no AF_UNIX, but we could
> maybe limit it to 127.0.0.1 and ::1.
>
> However, removing support for TCP would break one of the use-cases for
> which D-Bus-over-TCP was designed: sharing a bus on a trusted LAN,
> alongside a NFS home directory, DBUS_COOKIE_SHA1 (proving you can access
> $HOME) for authentication, and probably shared X11
> <http://lists.freedesktop.org/archives/dbus/2008-July/010176.html>. This
> is clearly not very secure either - it requires absolute trust in every
> machine on your LAN, which was maybe acceptable in the late 90s/early
> 00s, but now it's 2015 and maybe that isn't relevant any more?
>
> (Or maybe people still use that facility and will complain bitterly if
> we try to take it away. I don't know.)
>
>> 2) Using the ANONYMOUS mechanism  (related to #1)
> I'm *very* tempted to remove <allow_anonymous/> support from dbus-daemon
> 1.11 (again, not from libdbus, just dbus-daemon). I'm having great
> difficulty seeing a valid use-case, particularly in a world where
> networks should be assumed to be untrusted, and the CPU time needed for
> secure encryption/authentication is negligible.
>
> Relevant feature request for it being added in the first place:
> https://bugs.freedesktop.org/show_bug.cgi?id=15393
>