1. 24 Nov, 2014 2 commits
  2. 22 Nov, 2014 2 commits
    • Simon McVittie's avatar
      Revert "config: change default auth_timeout to 5 seconds" · 02e1ddf9
      Simon McVittie authored
      This reverts commit 54d26df5.
      It appears this change may cause intermittent slow or failed boot,
      more commonly on slower/older machines, in at least Mageia and
      possibly also Debian. This would indicate that while the system
      is under load, system services are not completing authentication
      within 5 seconds.
      This change was not the main part of fixing CVE-2014-3639, but does
      help to mitigate that attack. As such, increasing this timeout makes
      the denial of service attack described by CVE-2014-3639 somewhat
      more effective: a local user connecting to the system bus repeatedly
      from many parallel processes can cause other users' attempts to
      connect to take longer.
      If your machine boots reliably with the shorter timeout, and
      resilience against local denial of service attacks is important
      to you, putting this in /etc/dbus-1/system-local.conf
      or a file matching /etc/dbus-1/system.d/*.conf can restore
      the lower limit:
            <limit name="auth_timeout">5000</limit>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
    • Simon McVittie's avatar
      Log to syslog when auth_timeout drops an incomplete connection · 29c64424
      Simon McVittie authored
      This is a symptom of either a denial of service attack, or a
      serious performance problem. Either way, sysadmins should know.
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=86431
  3. 14 Nov, 2014 3 commits
  4. 10 Nov, 2014 2 commits
  5. 06 Nov, 2014 2 commits
  6. 16 Sep, 2014 1 commit
  7. 15 Sep, 2014 13 commits
  8. 12 Sep, 2014 2 commits
  9. 07 Sep, 2014 1 commit
  10. 05 Sep, 2014 1 commit
  11. 04 Sep, 2014 1 commit
  12. 02 Jul, 2014 1 commit
  13. 30 Jun, 2014 3 commits
  14. 11 Jun, 2014 2 commits
  15. 10 Jun, 2014 1 commit
  16. 05 Jun, 2014 2 commits
    • Simon McVittie's avatar
      Prepare embargoed security release · c3650785
      Simon McVittie authored
    • 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: default avatarSimon McVittie <simon.mcvittie@collabora.co.uk>
      Reviewed-by: Colin Walters's avatarColin Walters <walters@verbum.org>
  17. 30 Apr, 2014 1 commit