OpenVPN's use of Netfilter makes it susceptible to several attacks that can cause denial-of-service, deanonymization of clients, or redirection of a victim client connection to an attacker controlled server. Reference: https://www.openwall.com/lists/oss-security/2021/09/08/3 https://breakpointingbad.com/2021/09/08/Port-Shadows-via-Network-Alchemy.html
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2006005]
I wont be argueing the rescore, complexit is high, because the argued example is not in most openvpn nat scenarios, and even then you wont get I:H, because you can't modify anything.. Dunno what to say.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:1975 https://access.redhat.com/errata/RHSA-2022:1975
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:1988 https://access.redhat.com/errata/RHSA-2022:1988
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-2021-3773
(In reply to Wade Mealing from comment #7) > I wont be argueing the rescore, complexit is high, because the argued > example is not in most openvpn nat scenarios, and even then you wont get > I:H, because you can't modify anything.. Dunno what to say. Hi Wade, I have two questions I am hoping you can answer. First, what do you think are more common openvpn nat scenarios? Second, what is I:H?
> First, what do you think are more common openvpn nat scenarios? Commercial NAT systems (used to be cisco pix firewalls, etc). There was also a configuration that I'm aware of a private network on "the cloud" which had VPN connections out to another cloud and routed between them. > I:H Apologies, its been a while. IIRC it was because you had the ability also modify data on the server to attack the client, it might even be a little more. I have since changed positions in Red Hat and didnt keep notes on this, sorry about that.