1. 02 Jan, 2015 1 commit
  2. 24 Nov, 2014 1 commit
  3. 06 Nov, 2014 1 commit
  4. 15 Sep, 2014 7 commits
    • Simon McVittie's avatar
      Imported Upstream version 1.8.8 · 403920f7
      Simon McVittie authored
      403920f7
    • Alban Crequy's avatar
      bus: enforce pending_fd_timeout · e0c9d31b
      Alban Crequy authored
      This is one of four commits needed to address CVE-2014-3637.
      
      The bus uses _dbus_connection_set_pending_fds_function and
      _dbus_connection_get_pending_fds_count to be notified when there are pending
      file descriptors. A timeout per connection is armed and disarmed when the file
      descriptor list is used and emptied.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559Reviewed-by: 's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      e0c9d31b
    • Alban Crequy's avatar
      config: add new limit: pending_fd_timeout · bbf11cd5
      Alban Crequy authored
      This is one of four commits needed to address CVE-2014-3637.
      
      When a file descriptor is passed to dbus-daemon, the associated D-Bus message
      might not be fully sent to dbus-daemon yet. Dbus-daemon keeps the file
      descriptor in the DBusMessageLoader of the connection, waiting for the rest of
      the message. If the client stops sending the remaining bytes, dbus-daemon will
      wait forever and keep that file descriptor.
      
      This patch adds pending_fd_timeout (milliseconds) in the configuration to
      disconnect a connection after a timeout when a file descriptor was sent but not
      the remaining message.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80559Reviewed-by: 's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      bbf11cd5
    • Alban Crequy's avatar
      Stop listening on DBusServer sockets when reaching max_incomplete_connections · 8ad179a8
      Alban Crequy authored
      This addresses the parts of CVE-2014-3639 not already addressed by
      reducing the default authentication timeout.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80851
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919Reviewed-by: 's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      8ad179a8
    • Alban Crequy's avatar
      config: change default auth_timeout to 5 seconds · 54d26df5
      Alban Crequy authored
      This partially addresses CVE-2014-3639.
      
      This will change the default on the system bus where the limit
        <limit name="auth_timeout">...</limit>
      is not specified.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80919Reviewed-by: 's avatarThiago Macieira <thiago@kde.org>
      Reviewed-by: 's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      54d26df5
    • Simon McVittie's avatar
      config: change DEFAULT_MESSAGE_UNIX_FDS to 16 · 6465e37c
      Simon McVittie authored
      This addresses CVE-2014-3636.
      
      Based on a patch by Alban Crequy. Now that it's the same on all
      platforms, there's little point in it being set by configure/cmake.
      
      This change fixes two distinct denials of service:
      
      fd.o#82820, part A
      ------------------
      
      Before this patch, the system bus had the following default configuration:
      - max_connections_per_user: 256
      - DBUS_DEFAULT_MESSAGE_UNIX_FDS: usually 1024 (or 256 on QNX, see fd.o#61176)
        as defined by configure.ac
      - max_incoming_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
      - max_outgoing_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS*4 = usually 4096
      - max_message_unix_fds: DBUS_DEFAULT_MESSAGE_UNIX_FDS = usually 1024
      
      This means that a single user could create 256 connections and transmit
      256*4096 = 1048576 file descriptors.
      
      The file descriptors stay attached to the dbus-daemon process while they are
      in the message loader, in the outgoing queue or waiting to be dispatched before
      D-Bus activation.
      
      dbus-daemon is usually limited to 65536 file descriptors (ulimit -n). If the
      limit is reached and dbus-daemon needs to receive a message with a file
      descriptor attached, this is signalled by recvfrom with the flag MSG_CTRUNC.
      Dbus-daemon cannot recover from that error because the kernel does not have any
      API to retrieve a file descriptor which has been discarded with MSG_CTRUNC.
      Therefore, it closes the connection of the sender. This is not necessarily the
      connection which generated the most file descriptors so it can lead to
      denial-of-service attacks.
      
      In order to prevent DoS issues, this patch reduces DEFAULT_MESSAGE_UNIX_FDS to
      16:
      
      max_connections_per_user * max_incoming_unix_fds = 256 * 64 = 16384
      
      This is less than the usual "ulimit -n" (65536) with a good margin to
      accomodate the other sources of file descriptors (stdin/stdout/stderr,
      listening sockets, message loader, etc.).
      
      Distributors on non-Linux may need to configure a smaller limit in
      system.conf, if their limit on the number of fds is smaller than
      Linux's.
      
      fd.o#82820, part B
      ------------------
      
      On Linux, it's not possible to send more than 253 fds in a single sendmsg()
      call: sendmsg() would return -EINVAL.
        #define SCM_MAX_FD      253
      
      SCM_MAX_FD changed value during Linux history:
      - it used to be (OPEN_MAX-1)
      - commit c09edd6eb (Jul 2007) changed it to 255
      - commit bba14de98 (Nov 2010) changed it to 253
      
      Libdbus always sends all of a message's fds, and the beginning
      of the message itself, in a single sendmsg() call. Combining these
      two, a malicious sender could split a message across two or more
      sendmsg() calls to construct a composite message with 254 or more
      fds. When dbus-daemon attempted to relay that message to its
      recipient in a single sendmsg() call, it would receive EINVAL,
      interpret that as a fatal socket error and disconnect the recipient,
      resulting in denial of service.
      
      This is fixed by keeping max_message_unix_fds <= SCM_MAX_FD.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82820Reviewed-by: 's avatarAlban Crequy <alban.crequy@collabora.co.uk>
      6465e37c
    • Alban Crequy's avatar
  5. 04 Sep, 2014 1 commit
  6. 05 Jun, 2014 2 commits
    • Simon McVittie's avatar
      Imported Upstream version 1.8.4 · 2aa65581
      Simon McVittie authored
      2aa65581
    • Alban Crequy's avatar
      CVE-2014-3477: deliver activation errors correctly, fixing Denial of Service · 24c59070
      Alban Crequy authored
      How it should work:
      
      When a D-Bus message activates a service, LSMs (SELinux or AppArmor) check
      whether the message can be delivered after the service has been activated. The
      service is considered activated when its well-known name is requested with
      org.freedesktop.DBus.RequestName. When the message delivery is denied, the
      service stays activated but should not receive the activating message (the
      message which triggered the activation). dbus-daemon is supposed to drop the
      activating message and reply to the sender with a D-Bus error message.
      
      However, it does not work as expected:
      
      1. The error message is delivered to the service instead of being delivered to
         the sender. As an example, the error message could be something like:
      
           An SELinux policy prevents this sender from sending this
           message to this recipient, [...] member="MaliciousMethod"
      
         If the sender and the service are malicious confederates and agree on a
         protocol to insert information in the member name, the sender can leak
         information to the service, even though the LSM attempted to block the
         communication between the sender and the service.
      
      2. The error message is delivered as a reply to the RequestName call from
         service. It means the activated service will believe it cannot request the
         name and might exit. The sender could activate the service frequently and
         systemd will give up activating it. Thus the denial of service.
      
      The following changes fix the bug:
      - bus_activation_send_pending_auto_activation_messages() only returns an error
        in case of OOM. The prototype is changed to return TRUE, or FALSE on OOM
        (and its only caller sets the OOM error).
      - When a client is not allowed to talk to the service, a D-Bus error message
        is pre-allocated to be delivered to the client as part of the transaction.
        The error is not propagated to the caller so RequestName will not fail
        (except on OOM).
      
      [fixed a misleading comment -smcv]
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=78979Reviewed-by: 's avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: 's avatarColin Walters <walters@verbum.org>
      24c59070
  7. 28 Apr, 2014 1 commit
  8. 17 Jan, 2014 3 commits
  9. 14 Jan, 2014 1 commit
  10. 06 Jan, 2014 5 commits
  11. 12 Nov, 2013 1 commit
  12. 07 Nov, 2013 1 commit
  13. 01 Nov, 2013 4 commits
  14. 23 Oct, 2013 1 commit
  15. 09 Oct, 2013 2 commits
  16. 23 Sep, 2013 1 commit
  17. 13 Sep, 2013 1 commit
  18. 03 Sep, 2013 1 commit
  19. 30 Aug, 2013 1 commit
  20. 29 Aug, 2013 1 commit
  21. 23 Aug, 2013 3 commits