A security issue was discovered in tigervnc related how the viewers handle TLS certificate exceptions. Tigervnc before 1.11.0 stored the certificates as authorities, meaning that the owner of that certificate could impersonate any server it wanted after a client had added an exception. Tigervnc 1.11.0 handles this properly by only storing exceptions for specific hostname/certificate combinations, as done by HTTP user agents or SSH. References: https://github.com/TigerVNC/tigervnc/releases/tag/v1.11.0 https://github.com/TigerVNC/tigervnc/commit/f029745f63ac7d22fb91639b2cb5b3ab56134d6e https://github.com/TigerVNC/tigervnc/commit/b30f10c681ec87720cff85d490f67098568a9cba https://github.com/TigerVNC/tigervnc/commit/20dea801e747318525a5859fe4f37c52b05310cb https://github.com/TigerVNC/tigervnc/commit/7399eab79a4365434d26494fa1628ce1eb91562b https://bugzilla.opensuse.org/show_bug.cgi?id=1176733
Mitigation: This flaw can be mitigated by not making certificate exceptions in the affected versions of tigervnc, and therefore they will not be stored as authorities.
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-26117
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1783 https://access.redhat.com/errata/RHSA-2021:1783