1. 14 May, 2015 1 commit
  2. 12 May, 2015 1 commit
    • Simon McVittie's avatar
      Security hardening: force EXTERNAL auth in session.conf on Unix · d9ab8931
      Simon McVittie authored
      DBUS_COOKIE_SHA1 is dependent on unguessable strings, i.e.
      indirectly dependent on high-quality pseudo-random numbers
      whereas EXTERNAL authentication (credentials-passing)
      is mediated by the kernel and cannot be faked.
      On Windows, EXTERNAL authentication is not available,
      so we continue to use the hard-coded default (all
      authentication mechanisms are tried).
      Users of tcp: or nonce-tcp: on Unix will have to comment
      this out, but they would have had to use a special
      configuration anyway (to set the listening address),
      and the tcp: and nonce-tcp: transports are inherently
      insecure unless special steps are taken to have them
      restricted to a VPN or SSH tunnelling.
      Users of obscure Unix platforms (those that trigger
      the warning "Socket credentials not supported on this Unix OS"
      when compiling dbus-sysdeps-unix.c) might also have to
      comment this out, or preferably provide a tested patch
      to enable credentials-passing on that OS.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90414
  3. 05 Feb, 2015 1 commit
  4. 04 Feb, 2015 1 commit
  5. 05 Jan, 2015 1 commit
  6. 01 Jan, 2015 1 commit
  7. 24 Nov, 2014 2 commits
  8. 10 Nov, 2014 1 commit
  9. 06 Nov, 2014 1 commit
  10. 16 Sep, 2014 1 commit
  11. 15 Sep, 2014 3 commits
    • Simon McVittie's avatar
      Prepare 1.8.8 (embargoed until tomorrow) · 28cba657
      Simon McVittie authored
    • 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
      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
      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: default avatarAlban Crequy <alban.crequy@collabora.co.uk>
    • Simon McVittie's avatar
      On Linux, call prctl to disable core dumps · ae50d46f
      Simon McVittie authored
      Whenever I forget to turn off corekeeper, the regression tests
      take ages to record all test-segfault's crashes.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83772Reviewed-by: default avatarAlban Crequy <alban.crequy@collabora.co.uk>
  12. 12 Sep, 2014 1 commit
  13. 02 Jul, 2014 1 commit
  14. 30 Jun, 2014 1 commit
  15. 10 Jun, 2014 1 commit
  16. 05 Jun, 2014 1 commit
  17. 30 Apr, 2014 2 commits
  18. 27 Jan, 2014 1 commit
  19. 20 Jan, 2014 2 commits
  20. 06 Jan, 2014 3 commits
  21. 27 Nov, 2013 1 commit
  22. 01 Nov, 2013 5 commits
  23. 10 Oct, 2013 1 commit
  24. 09 Oct, 2013 2 commits
  25. 08 Oct, 2013 4 commits