1. 02 Jul, 2020 5 commits
    • Simon McVittie's avatar
      v1.10.32 · fd89df43
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      Update NEWS · 38fe525f
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      userdb: Reference-count DBusUserInfo, DBusGroupInfo · dc94fe3d
      Simon McVittie authored
      Previously, the hash table indexed by uid (or gid) took ownership of the
      single reference to the heap-allocated struct, and the hash table
      indexed by username (or group name) had a borrowed pointer to the same
      struct that exists in the other hash table.
      However, this can break down if you have two or more distinct usernames
      that share a numeric identifier. This is generally a bad idea, because
      the user-space model in such situations does not match the kernel-space
      reality, and in particular there is no effective kernel-level security
      boundary between such users, but it is sometimes done anyway.
      In this case, when the second username is looked up in the userdb, it
      overwrites (replaces) the entry in the hash table that is indexed by
      uid, freeing the DBusUserInfo. This results in both the key and the
      value in the hash table that is indexed by username becoming dangling
      pointers (use-after-free), leading to undefined behaviour, which is
      certainly not what we want to see when doing access control.
      An equivalent situation can occur with groups, in the rare case where
      a numeric group ID has two names (although I have not heard of this
      being done in practice).
      Solve this by reference-counting the data structure. There are up to
      three references in practice: one held temporarily while the lookup
      function is populating and storing it, one held by the hash table that
      is indexed by uid, and one held by the hash table that is indexed by
      Closes: #305Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      (cherry picked from commit 2b7948ef)
    • Simon McVittie's avatar
      userdb: Make lookups return a const pointer · 4ed1b320
      Simon McVittie authored
      This makes it more obvious that the returned pointer points to a
      struct owned by the userdb, which must not be freed or have its
      contents modified, and is only valid to dereference until the next
      modification to the userdb's underlying hash tables (which in practice
      means until the lock is released, because after that we have no
      guarantees about what might be going on in another thread).
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      (cherry picked from commit 6ee66ff7)
    • Andy Fiddaman's avatar
      Solaris and derivatives do not adjust cmsg_len on MSG_CTRUNC · 80f7e5b2
      Andy Fiddaman authored
      (cherry picked from commit b96ef23e)
  2. 02 Jun, 2020 4 commits
  3. 20 Feb, 2020 1 commit
    • Simon McVittie's avatar
      bus: Don't explicitly clear BusConnections.monitors · 3643fd25
      Simon McVittie authored
      Each connection that is an active monitor holds a pointer to its own
      link in this list, via BusConnectionData.link_in_monitors. We can't
      validly free the list while these pointers exist: that would be a
      use-after-free, when each connection gets disconnected and tries to
      remove itself from the list.
      Instead, let each connection remove itself from the list, then assert
      that the list has become empty.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
  4. 11 Jun, 2019 1 commit
  5. 09 Jun, 2019 7 commits
    • Simon McVittie's avatar
      NEWS: Note additional fixes in doc/ · 983e62be
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      doc: Install highlight.pack.js if present · a66357c1
      Simon McVittie authored
      Newer versions of yelp-build use this instead of a jQuery syntax
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106171Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      [smcv: Also add it to .gitignore as suggested]
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      (cherry picked from commit 49ad5b11)
    • Simon McVittie's avatar
      build: Uninstall JavaScript and CSS from htmldir · 7ea360f3
      Simon McVittie authored
      Otherwise, distcheck fails when mallard-ducktype is available.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      (cherry picked from commit 9391d769)
      (cherry picked from commit 08e48ca6)
    • Simon McVittie's avatar
      doc: Only install ancillary files from yelp-build if they exist · 9c5a924a
      Simon McVittie authored
      Newer versions of yelp-build don't install jquery.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=106171Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      (cherry picked from commit bab857fb)
    • Simon McVittie's avatar
      Prepare version 1.10.28 · f3ab0e45
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      test: Add basic test coverage for DBUS_COOKIE_SHA1 · c251e7ea
      Simon McVittie authored
      We don't actually complete successful authentication, because that
      would require us to generate a cookie and compute the correct SHA1,
      which is difficult to do in a deterministic authentication script.
      However, we do assert that #269 (CVE-2019-12749) has been fixed.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
    • Simon McVittie's avatar
      auth: Reject DBUS_COOKIE_SHA1 for users other than the server owner · 525c2314
      Simon McVittie authored
      The DBUS_COOKIE_SHA1 authentication mechanism aims to prove ownership
      of a shared home directory by having the server write a secret "cookie"
      into a .dbus-keyrings subdirectory of the desired identity's home
      directory with 0700 permissions, and having the client prove that it can
      read the cookie. This never actually worked for non-malicious clients in
      the case where server uid != client uid (unless the server and client
      both have privileges, such as Linux CAP_DAC_OVERRIDE or traditional
      Unix uid 0) because an unprivileged server would fail to write out the
      cookie, and an unprivileged client would be unable to read the resulting
      file owned by the server.
      Additionally, since dbus 1.7.10 we have checked that ~/.dbus-keyrings
      is owned by the uid of the server (a side-effect of a check added to
      harden our use of XDG_RUNTIME_DIR), further ruling out successful use
      by a non-malicious client with a uid differing from the server's.
      Joe Vennix of Apple Information Security discovered that the
      implementation of DBUS_COOKIE_SHA1 was susceptible to a symbolic link
      attack: a malicious client with write access to its own home directory
      could manipulate a ~/.dbus-keyrings symlink to cause the DBusServer to
      read and write in unintended locations. In the worst case this could
      result in the DBusServer reusing a cookie that is known to the
      malicious client, and treating that cookie as evidence that a subsequent
      client connection came from an attacker-chosen uid, allowing
      authentication bypass.
      This is mitigated by the fact that by default, the well-known system
      dbus-daemon (since 2003) and the well-known session dbus-daemon (in
      stable releases since dbus 1.10.0 in 2015) only accept the EXTERNAL
      authentication mechanism, and as a result will reject DBUS_COOKIE_SHA1
      at an early stage, before manipulating cookies. As a result, this
      vulnerability only applies to:
      * system or session dbus-daemons with non-standard configuration
      * third-party dbus-daemon invocations such as at-spi2-core (although
        in practice at-spi2-core also only accepts EXTERNAL by default)
      * third-party uses of DBusServer such as the one in Upstart
      Avoiding symlink attacks in a portable way is difficult, because APIs
      like openat() and Linux /proc/self/fd are not universally available.
      However, because DBUS_COOKIE_SHA1 already doesn't work in practice for
      a non-matching uid, we can solve this vulnerability in an easier way
      without regressions, by rejecting it early (before looking at
      ~/.dbus-keyrings) whenever the requested identity doesn't match the
      identity of the process hosting the DBusServer.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Closes: #269
      Closes: CVE-2019-12749
  6. 03 Dec, 2018 4 commits
  7. 05 Oct, 2018 1 commit
  8. 04 Oct, 2018 9 commits
  9. 30 Aug, 2018 2 commits
  10. 03 Aug, 2018 1 commit
  11. 02 Aug, 2018 5 commits