A security issue was discovered in current versions of libseccomp where the library did not correctly generate 64-bit syscall argument comparisons using the arithmetic operators (LT, GT, LE, GE).It would appear that only systemd and Tor are using libseccomp in such a way as to trigger the bad code. In the case of systemd this appears to affect the socket address family and scheduling class filters. In the case of Tor it appears that the bad filters could impact the memory addresses passed to mprotect(2). Reference: https://www.openwall.com/lists/oss-security/2019/03/15/1 Commits: https://github.com/seccomp/libseccomp/commit/c5bf78de480b32b324e0f511c88ce533ed280b37 https://github.com/seccomp/libseccomp/commit/cf5d1538d243fb6f1839db70b69469d3d7e9e077 https://github.com/seccomp/libseccomp/commit/2878b8ba7859cf1771795ebef5c85ec211756dca https://github.com/seccomp/libseccomp/commit/3da42d78e26cd16282bee85fcd817115b7f91af0 https://github.com/seccomp/libseccomp/commit/b29eda913b11ca339a7c1727fdc7e3309dd2a9b6
Created libseccomp tracking bugs for this issue: Affects: fedora-all [bug 1690898]
A libseccomp v2.4.0 package was released for F30, F29, and F28 using the BZs below: - F30 * https://bugzilla.redhat.com/show_bug.cgi?id=1688903 - F29 * https://bugzilla.redhat.com/show_bug.cgi?id=1688905 - F28 * https://bugzilla.redhat.com/show_bug.cgi?id=1688906
Upstream issue: https://github.com/seccomp/libseccomp/issues/139
Incrementing the Impact of the flaw to Important because those kind of vulnerable libseccomp's filters are used by systemd when restricting address families and they could be exploited to access families that should not be allowed. Moreover, they may be used by other packages as well.
Keeping the Impact of the flaw to Moderate as, after more analysis and feedback, this cannot be exploited directly and it doesn't have a direct impact on the shipped packages (systemd, flatpak, docker, etc.). An attacker would need to compromise a program/service first and then abuse the loose libseccomp filter somehow to get some advantages.
When comparisons like SCMP_CMP_GE, SCMP_CMP_GT, SCMP_CMP_LE, SCMP_CMP_LT are used in a seccomp filter, the generated code does not properly checks the values and it allows some values that should instead be blocked.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2019:3624 https://access.redhat.com/errata/RHSA-2019:3624
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-9893