Bug 2004949 (CVE-2021-3773)
| Summary: | CVE-2021-3773 kernel: lack of port sanity checking in natd and netfilter leads to exploit of OpenVPN clients | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Guilherme de Almeida Suckevicz <gsuckevi> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | acaringi, adscvr, airlied, alciregi, bdettelb, bhu, blc, bmixonba, brdeoliv, bskeggs, chwhite, crwood, dhoward, dvlasenk, fhrbata, fpacheco, hdegoede, hkrzesin, jarod, jarodwilson, jeremy, jforbes, jglisse, jlelli, jonathan, josef, jshortt, jstancek, jwboyer, kcarcia, kernel-maint, kernel-mgr, lgoncalv, linville, masami256, mchehab, mlangsdo, mrehak, nmurray, ptalbert, qzhao, rkeshri, rvrbovsk, steved, vkumar, walters, williams, wmealing |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | kernel 5.14.0-49.el9, kernel 5.15.15-100.fc34, kernel 5.15.15-200.fc35 | Doc Type: | If docs needed, set a value |
| Doc Text: |
A flaw in netfilter could allow a network-connected attacker to infer openvpn connection endpoint information for further use in traditional network attacks.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-11 10:16:30 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2006005, 2006167, 2006168, 2006169 | ||
| Bug Blocks: | 2001550, 2004199 | ||
|
Description
Guilherme de Almeida Suckevicz
2021-09-16 13:37:43 UTC
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. |