From 05d5a55f44111a8653a4eda7abbb8f69f0d18795 Mon Sep 17 00:00:00 2001
From: Simon McVittie <smcv@collabora.com>
Date: Tue, 12 Dec 2017 14:05:04 +0000
Subject: [PATCH 6/8] dbus-daemon: Filter out unknown header fields

Signed-off-by: Simon McVittie <smcv@collabora.com>
---
 bus/dispatch.c             | 10 ++++++++++
 bus/driver.c               | 12 +++++++++---
 doc/dbus-specification.xml | 25 ++++++++++++++++++++++++-
 3 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/bus/dispatch.c b/bus/dispatch.c
index 14bef989..4ae98b5e 100644
--- a/bus/dispatch.c
+++ b/bus/dispatch.c
@@ -34,6 +34,7 @@
 #include "signals.h"
 #include "test.h"
 #include <dbus/dbus-internals.h>
+#include <dbus/dbus-message-internal.h>
 #include <dbus/dbus-misc.h>
 #include <dbus/dbus-test-tap.h>
 #include <string.h>
@@ -287,6 +288,15 @@ bus_dispatch (DBusConnection *connection,
         }
     }
 
+  /* Make sure the message does not have any header fields that we
+   * don't understand (or validate), so that we can add header fields
+   * in future and clients can assume that we have checked them. */
+  if (!_dbus_message_remove_unknown_fields (message))
+    {
+      BUS_SET_OOM (&error);
+      goto out;
+    }
+
   service_name = dbus_message_get_destination (message);
 
 #ifdef DBUS_ENABLE_VERBOSE_MODE
diff --git a/bus/driver.c b/bus/driver.c
index cd0a714d..0204aea2 100644
--- a/bus/driver.c
+++ b/bus/driver.c
@@ -2984,6 +2984,7 @@ features_getter (BusContext      *context,
                  DBusMessageIter *variant_iter)
 {
   DBusMessageIter arr_iter;
+  const char *s;
 
   if (!dbus_message_iter_open_container (variant_iter, DBUS_TYPE_ARRAY,
                                          DBUS_TYPE_STRING_AS_STRING,
@@ -2992,15 +2993,20 @@ features_getter (BusContext      *context,
 
   if (bus_apparmor_enabled ())
     {
-      const char *s = "AppArmor";
+      s = "AppArmor";
 
       if (!dbus_message_iter_append_basic (&arr_iter, DBUS_TYPE_STRING, &s))
         goto abandon;
     }
 
+  s = "HeaderFiltering";
+
+  if (!dbus_message_iter_append_basic (&arr_iter, DBUS_TYPE_STRING, &s))
+    goto abandon;
+
   if (bus_selinux_enabled ())
     {
-      const char *s = "SELinux";
+      s = "SELinux";
 
       if (!dbus_message_iter_append_basic (&arr_iter, DBUS_TYPE_STRING, &s))
         goto abandon;
@@ -3008,7 +3014,7 @@ features_getter (BusContext      *context,
 
   if (bus_context_get_systemd_activation (context))
     {
-      const char *s = "SystemdActivation";
+      s = "SystemdActivation";
 
       if (!dbus_message_iter_append_basic (&arr_iter, DBUS_TYPE_STRING, &s))
         goto abandon;
diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml
index fd46f537..bbd29eb2 100644
--- a/doc/dbus-specification.xml
+++ b/doc/dbus-specification.xml
@@ -1618,7 +1618,10 @@
           mutually-distrustful client to another, such as the message
           bus, should remove header fields that the server does not
           recognise. However, a client must assume that the server has
-          not done so, unless it has evidence to the contrary.
+          not done so, unless it has evidence to the contrary,
+          such as having checked for the <literal>HeaderFiltering</literal>
+          <link linkend="message-bus-properties-features">message bus
+            feature</link>.
         </para>
 
         <para>
@@ -6983,6 +6986,26 @@
               </listitem>
             </varlistentry>
 
+            <varlistentry>
+              <term><literal>HeaderFiltering</literal></term>
+              <listitem>
+                <para>
+                  This message bus guarantees that it will remove
+                  header fields that it does not understand when it
+                  relays messages, so that a client receiving a
+                  recently-defined header field that is specified to be
+                  controlled by the message bus can safely assume that
+                  it was in fact set by the message bus. This check is
+                  needed because older message bus implementations did
+                  not guarantee to filter headers in this way, so a
+                  malicious client could send any recently-defined
+                  header field with a crafted value of its choice
+                  through an older message bus that did not understand
+                  that header field.
+                </para>
+              </listitem>
+            </varlistentry>
+
             <varlistentry>
               <term><literal>SELinux</literal></term>
               <listitem>
-- 
2.15.1