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

(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

-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>

_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus