1. 18 Sep, 2014 1 commit
  2. 15 Sep, 2014 3 commits
    • Ralf Habacker's avatar
      Fix installation of empty directories for cmake build system. · 6864780b
      Ralf Habacker authored
      The differences has been found out by comparing with the cross compiled
      mingw..-dbus packages.
      
      [exclude system bus support bits on Windows -smcv]
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83583Reviewed-by: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      6864780b
    • Simon McVittie's avatar
      Make various system-bus-related things Unix-only · 87448fed
      Simon McVittie authored
      There is no system bus on Windows, and there won't be until/unless
      it can be secure.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83583Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      87448fed
    • 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: default avatarAlban Crequy <alban.crequy@collabora.co.uk>
      6465e37c
  3. 08 Sep, 2014 1 commit
  4. 08 Aug, 2014 1 commit
  5. 20 Mar, 2014 1 commit
  6. 19 Feb, 2014 1 commit
  7. 30 Jan, 2014 1 commit
  8. 27 Jan, 2014 1 commit
  9. 21 Jan, 2014 1 commit
  10. 17 Jan, 2014 7 commits
  11. 10 Jan, 2014 3 commits
  12. 09 Jan, 2014 3 commits
  13. 08 Jan, 2014 1 commit
  14. 07 Jan, 2014 1 commit
  15. 27 Nov, 2013 1 commit
  16. 08 Oct, 2013 1 commit
  17. 16 Sep, 2013 2 commits
    • Simon McVittie's avatar
      Remove support for platforms with no 64-bit integer type · b47d5062
      Simon McVittie authored
      This has been a soft requirement since 1.5.0; anyone on such platforms
      would have had to configure --without-64-bit, provoking a warning that
      instructed them to report a D-Bus bug with details of their platform.
      Nobody has done so, so if anyone still lacks a 64-bit integer type,
      they're on their own.
      
      (Also, I tried the build with --without-64-bit and it's full of
      fatal compiler warnings, so it's not clear that we're actually
      losing anything by removing this "feature".)
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65429Reviewed-by: default avatarChengwei Yang <chengwei.yang@intel.com>
      b47d5062
    • Simon McVittie's avatar
      dbus-sysdeps-win: don't include wspiapi.h · 3b9c2817
      Simon McVittie authored
      This block provoked a warning on mingw-w64 because we were redefining
      _inline. According to Ralf's research, it was introduced in 452ff68a:
      Windows 2000 doesn't have getaddrinfo and related functions in
      ws2tcpip.h, but does have a shim implementation in wspiapi.h.
      
      At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
      why there was a __GNUC__ code path here. The "#define _inline" on that
      code path looks likely to be some sort of workaround for a faulty version
      of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
      __GNUC__ code path and get the redefinition.
      
      dbus no longer supports Windows 2000, so we no longer need wspiapi.h
      at all, and can rely on XP or later. (Ralf's policy is to only support
      versions of Windows that are still supported by Microsoft, and Windows 2000
      reached the end of its life-cycle in 2010.)
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
      Reviewed-by: Ralf Habacker
      3b9c2817
  18. 03 Sep, 2013 2 commits
  19. 28 Aug, 2013 2 commits
  20. 23 Aug, 2013 1 commit
  21. 22 Aug, 2013 1 commit
  22. 01 Jul, 2013 1 commit
  23. 28 Jun, 2013 3 commits