Security concerns on the Windows DBUS port

[Fan Wu]

Thanks for the response Ralf!

I think the problem with windows named pipe is you can't do poll on
it. If so the problem can probably be solved by adding a wrapper
around WaitforMultipleObjects().

The auto-launch support is not enough to secure/authenticate the TCP
connection. The fundamental issue is you can't trust the information
"as told" by the peer. You can only trust the info as told by the OS,
like the credentials passed in Unix Domain socket. Or in WIndows Vista
(ONLY), the named pipe  server can obtain peer credentials thru calls
like GetNamedPipeClientProcessID().

With TCP socket (XP and Vista only) you can call GetExtendedTcpTable()
to enumerate opened TCP sockets and find their PIDs. But again I don't
think using TCP for transport is a serious solution or a solution of
"industrial strength".

Cheers,
Fan

On 4/7/07, Ralf Habacker <ralf.habacker at freenet.de> wrote:
> Fan Wu schrieb:
> > Hi all,
> >
> > I have couple of concerns on the Windows DBUS port. I've tried digging
> > into the archive but haven't found answers to my questions.
> >
> > I think the current windbus implementation using TCP socket is mainly
> > because it's hard to find a counterpart of Unix domain socket in
> > windows. But the problems with TCP socket are
> >
> > 1) possible conflict with personal firewall
> >
> > One of the projects I worked on used TCP socket of localhost for IPC,
> > and there are many cases that firewall has caused our products
> > useless. The percentage is small but the sheer number is large due to
> > the large installation base.
> There was a try to implement named pipes see
> http://webcvs.freedesktop.org/dbus/dbus/README.win?view=markup
>
> ".. there are some efforts to get named pipe running, but some
> design problems of the win32 api, we are not able to solve without
> bigger changes to the dbus code base let us stop this effort."
>
>
> > 2) how do you know the client is telling the truth about the user
> > credential (sid)?
> >
> > With Unix domain socket the OS is making sure the credentials passed
> > thru the socket is right (not faked). With TCP socket you are not
> > getting such help from the OS and you can't be sure the other end of
> > the transport is using libdbus to talk to you. So it's possible a
> > rogue application may use its own client side dbus implementation to
> > spoof a legitimate user.
> >
> > I'm not arguing DBUS shall fend against the case when the whole
> > machine has been 0wned, but I do expect the authentication in DBUS can
> > raise the bar higher.
> The recent windows implementation has a kind of autolaunch support by
> using a shared memory area, in which the dbus-daemon stores his
> connection informations. See
> http://webcvs.freedesktop.org/dbus/dbus/dbus/dbus-sysdeps-win.c?view=markup
> for more informations.
> There related functions are
>  _dbus_daemon_init(), _dbus_daemon_release(), which handles the shm area
> on the server side and
> _dbus_get_autolaunch_shm() which retrieves the related informations for
> the client side.
>
> I haven't written the implementation but this feature may be used to
> secure the tcp connection.
>
> Patches are welcome.
>
> Regards
> Ralf
>
>