A flaw was discovered in dbus where the implementation of DBUS_COOKIE_SHA1 is 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. This could result in authentication bypass.
Acknowledgments: Name: the D-Bus project Upstream: Joe Vennix (Apple Information Security)
Its public now: https://www.openwall.com/lists/oss-security/2019/06/11/2
Upstream patch: https://gitlab.freedesktop.org/dbus/dbus/commit/47b1a4c41004bf494b87370987b222c934b19016
Created dbus tracking bugs for this issue: Affects: fedora-all [bug 1720995]
As per upstream: 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. Red Hat Enterprise Linux 7 and 8, both ship dbus >= 1.10 and therefore are affected by this flaw only when system or session dbus-daemons are used under non-standard configurations or by third party users of DBusServer. Either of these use-cases are not applicable to Red Hat Enterprise Linux.
External References: https://www.openwall.com/lists/oss-security/2019/06/11/2
Statement: This flaw 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. Red Hat Enterprise Linux 6 is affected by this flaw, which can be leveraged to achieve privilege escalation via upstart. This issue has been rated as having important impact for Red Hat Enterprise Linux 6. Red Hat Enterprise Linux 7 and 8, both ship dbus >= 1.10 and therefore are affected by this flaw only when system or session dbus-daemons are used under non-standard configurations or by third party users of DBusServer. Red Hat Enterprise Linux 7 and 8 does not ship any affected DBusServer cosumer. However third party applications may be affected.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2019:1726 https://access.redhat.com/errata/RHSA-2019:1726
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-12749
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.5 Advanced Update Support Via RHSA-2019:2870 https://access.redhat.com/errata/RHSA-2019:2870
This issue has been addressed in the following products: Red Hat Enterprise Linux 6.6 Advanced Update Support Via RHSA-2019:2868 https://access.redhat.com/errata/RHSA-2019:2868
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3707 https://access.redhat.com/errata/RHSA-2019:3707
Hi, I see here this is closed and I see fixes for rhel 8 and rhel 6. But not for RHEL 7, which in https://access.redhat.com/security/cve/CVE-2019-12749 states they won't fix on rhel 7. Is any specific reason not to fix in RHEL 7? I see the Upstream patch: https://gitlab.freedesktop.org/dbus/dbus/commit/47b1a4c41004bf494b87370987b222c934b19016
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:4032 https://access.redhat.com/errata/RHSA-2020:4032