Attachment 106127 Details for Bug 83499 – dbus-sysdeps-win: document the credentials assumptions that we're making

[patch] dbus-sysdeps-win: document the credentials assumptions that we're making

0002-dbus-sysdeps-win-document-the-credentials-assumption.patch (text/plain), 2.59 KB, created by Simon McVittie on 2014-09-11 12:21:21 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Simon McVittie

Created: 2014-09-11 12:21:21 UTC

Size: 2.59 KB

patch

obsolete

>From 6849a8ccb97056464e1af0156fe4bc1f8e5100fe Mon Sep 17 00:00:00 2001
>From: Simon McVittie <simon.mcvittie@collabora.co.uk>
>Date: Thu, 11 Sep 2014 13:14:10 +0100
>Subject: [PATCH 2/2] dbus-sysdeps-win: document the credentials assumptions
> that we're making
>
>Unlike on Unix, I'm not at all sure that these assumptions are
>actually valid. If they're not, we should revert the features
>added in 1.7.2 and 1.7.6 for fd.o#61787 and fd.o#66060, and
>instead report that all bus clients have an unknown uid and pid.
>---
> dbus/dbus-sysdeps-win.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
>diff --git a/dbus/dbus-sysdeps-win.c b/dbus/dbus-sysdeps-win.c
>index 341db8a..70f8ced 100644
>--- a/dbus/dbus-sysdeps-win.c
>+++ b/dbus/dbus-sysdeps-win.c
>@@ -240,6 +240,27 @@ get_pid_from_tcp_ex_table(int peer_port)
>  * @brief return peer process id from tcp handle for localhost connections
>  * @param handle tcp socket descriptor
>  * @return process id or 0 in case the process id could not be fetched
>+ *
>+ * Security-sensitive assumptions made by this method:
>+ *
>+ * - we assume that a Windows TCP client cannot queue up the rest of the
>+ *   authentication handshake and a malicious message in its outgoing
>+ *   TCP socket buffer, then arrange to be replaced by a more-privileged
>+ *   process with the same process ID, while leaving its TCP connection open
>+ *   and leaving those messages pending
>+ *   (the equivalent on Unix is specifically not true, because the process
>+ *   could exec() a setuid binary)
>+ *
>+ * - we assume that a Windows TCP client cannot queue up data as above,
>+ *   then pass its TCP client endpoint to a more privileged process,
>+ *   fooling the DBusServer into thinking the message was sent by
>+ *   the more privileged process
>+ *
>+ * - we assume that a Windows TCP client cannot queue up data as above,
>+ *   arrange for many processes to be started, then exit, such that its
>+ *   process ID will be re-used for a more privileged process
>+ *
>+ * FIXME: are those assumptions true?
>  */
> static dbus_pid_t
> _dbus_get_peer_pid_from_tcp_handle (int handle)
>@@ -1961,6 +1982,12 @@ _dbus_read_credentials_socket  (int              handle,
> 
>   _dbus_credentials_add_pid (credentials, pid);
> 
>+  /* FIXME: time of check / time of use error: can we guarantee
>+   * that a malicious process hasn't exited, while causing lots of
>+   * more privileged processes to be started, such that with high
>+   * probability, its process ID is re-used for one of the more
>+   * privileged processes?
>+   */
>   if (_dbus_getsid (&sid, pid))
>     {
>       if (!_dbus_credentials_add_windows_sid (credentials, sid))
>-- 
>2.1.0
>

Actions: View | Splinter Review

Attachments on bug 83499: 106126 | 106127 | 139047 | 139049 | 139075

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.