Hide Forgot
As per upstream: GSS-TSIG is an extension to the TSIG protocol which is intended to support the secure exchange of keys for use in verifying the authenticity of communications between parties on a network. SPNEGO is a negotiation mechanism used by GSSAPI, the application protocol interface for GSS-TSIG. The SPNEGO implementation used by BIND has been found to be vulnerable to a buffer overflow attack. The most likely outcome of a successful exploitation of the vulnerability is a crash of the named process. However, remote code execution, while unproven, is theoretically possible.
Acknowledgments: Name: ISC Upstream: Trend Micro Zero Day Initiative
Created attachment 1757035 [details] Patch against bind-9.11.28
Statement: BIND servers shipped with Red Hat Enterprise Linux are compiled with GSS-TSIG and are therefore affected by this flaw. However, these BIND packages use the default settings and are not vulnerable by default.
Mitigation: As per upstream: BIND servers are vulnerable if they are running an affected version and are configured to use GSS-TSIG features. In a configuration which uses BIND's default settings, the vulnerable code path is NOT exposed, but a server can be rendered vulnerable by explicitly setting valid values for the tkey-gssapi-keytab or tkey-gssapi-credentialconfiguration options. Although the default configuration is not vulnerable, GSS-TSIG is frequently used in networks where BIND is integrated with Samba, as well as in mixed-server environments that combine BIND servers with Active Directory domain controllers. This vulnerability only affects servers configured to use GSS-TSIG, most often to sign dynamic updates. If another mechanism can be used to authenticate updates, the vulnerability can be avoided by choosing not to enable the use of GSS-TSIG features.
External References: https://kb.isc.org/docs/cve-2020-8625
Created bind tracking bugs for this issue: Affects: fedora-all [bug 1929965]
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Extended Update Support Via RHSA-2021:0669 https://access.redhat.com/errata/RHSA-2021:0669
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:0670 https://access.redhat.com/errata/RHSA-2021:0670
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Extended Lifecycle Support Via RHSA-2021:0672 https://access.redhat.com/errata/RHSA-2021:0672
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2021:0671 https://access.redhat.com/errata/RHSA-2021:0671
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-2020-8625
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.2 Advanced Update Support Via RHSA-2021:0694 https://access.redhat.com/errata/RHSA-2021:0694
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.3 Advanced Update Support Via RHSA-2021:0693 https://access.redhat.com/errata/RHSA-2021:0693
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.4 Advanced Update Support Red Hat Enterprise Linux 7.4 Update Services for SAP Solutions Red Hat Enterprise Linux 7.4 Telco Extended Update Support Via RHSA-2021:0692 https://access.redhat.com/errata/RHSA-2021:0692
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.6 Extended Update Support Via RHSA-2021:0691 https://access.redhat.com/errata/RHSA-2021:0691
This issue has been addressed in the following products: Red Hat Enterprise Linux 7.7 Extended Update Support Via RHSA-2021:0727 https://access.redhat.com/errata/RHSA-2021:0727
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2021:0922 https://access.redhat.com/errata/RHSA-2021:0922
[root@atomic ~]# atomic host status State: idle; auto updates disabled Deployments: ● ostree://rhel79:rhel-atomic-host/7/x86_64/standard Version: 7.9.4 (2021-03-10 11:58:04) Commit: 322d1f2f1144dbf823f9f5e5295c0c7e9ec1ef7958b4648608f8ab46cb809bc6 GPGSignature: Valid signature by 567E347AD0044ADE55BA8A5F199E2F91FD431D51 ostree://rhel-atomic-host-ostree:rhel-atomic-host/7/x86_64/standard Version: 7.8.3 (2020-08-05 13:51:05) Commit: dfd383553c0f25c503272b0d193ac863f2deede0fa69278391bd2b1e6d02b56a GPGSignature: Valid signature by 567E347AD0044ADE55BA8A5F199E2F91FD431D51 [root@atomic ~]# atomic scan --scanner openscap --scan_type cve rhel7/sssd docker run -t --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2021-03-30-05-25-07-335441:/scanin -v /var/lib/atomic/openscap/2021-03-30-05-25-07-335441:/scanout:rw,Z -v /etc/oscapd:/etc/oscapd:ro registry.access.redhat.com/rhel7/openscap oscapd-evaluate scan --no-standard-compliance --targets chroots-in-dir:///scanin --output /scanout -j1 Unable to find image 'registry.access.redhat.com/rhel7/openscap:latest' locally Trying to pull repository registry.access.redhat.com/rhel7/openscap ... latest: Pulling from registry.access.redhat.com/rhel7/openscap 91592046c71b: Pulling fs layer b77bb434db5a: Pulling fs layer 846a26296394: Pulling fs layer b77bb434db5a: Verifying Checksum b77bb434db5a: Download complete 846a26296394: Verifying Checksum 846a26296394: Download complete 91592046c71b: Verifying Checksum 91592046c71b: Download complete 91592046c71b: Pull complete b77bb434db5a: Pull complete 846a26296394: Pull complete Digest: sha256:ca2e4f742915dd28477a4cd2fbb1732370351da1d5ac653f2809a6e855f8d6cd Status: Downloaded newer image for registry.access.redhat.com/rhel7/openscap:latest rhel7/sssd (94f10939941715d) rhel7/sssd passed the scan Files associated with this scan are in /var/lib/atomic/openscap/2021-03-30-05-25-07-335441. [root@atomic ~]# docker inspect rhel7/sssd | grep url "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/rhel7/sssd/images/7.9.1-12", "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/rhel7/sssd/images/7.9.1-12", SSSD as System-Container Sanity Services ======================================== Deny specific ad user login to Atomic host Passed Discover Windows Domain on atomic host using realm cli Passed Disjoin Atomic host from AD Domain using realm leave Cli Passed Join AD Domain using adcli as membership-software Passed Permit specific ad user login to Atomic host Passed Query AD user using id command from new container Passed Query AD users using ID command Passed Realm join with membership software samba Passed Verify sssd selinux label Passed Verify uninstall container leaves domain Passed SSSD container as Application Container ============================================ Create a sssd application container on Atomic host Passed Query AD users using ID command from sssd app container Passed Spawn sssd app container using realm join with adcli option Passed Verify sssd application container runs as unprivileged Passed kinit as AD User from sssd app container should be successfull Passed