From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Fwd: [oss-security] CVE-2021-3773: Lack of port sanity checking in natd and Netfilter leads to exploit of OpenVPN clients on Linux and FreeBSD platforms Date: Mon, 27 Sep 2021 13:08:52 +0200 Message-ID: <8a0c2f9b-109e-eb47-2730-cca875767f0f@ipfire.org> In-Reply-To: <380692de-0d51-914d-2430-ce629426890d@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5049698309850004233==" List-Id: --===============5049698309850004233== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Peter, I am definitely not in Erik's class in terms of OpenVPN understanding but I h= ave had a review of the material and here are my inputs and conclusions. It looks to me that the primary target is going to be related to VPN server p= roviders. The attacker has to have a connection to the same OpenVPN server as= the victim is connected to. There are two phases to the attack methodology. First a parallel connection t= hat uses the Port Shadowing issue that has been identified to de-anonymise th= e victim. Then with this information the attacker can set up an OpenVPN Clien= t to man in the middle attack. With this they then can use a recently disclos= ed attack (Tolley 2021) against OpenVPN servers. This allows the victim to be= sent to an attacker controlled server. For this to provide something usable = apparently the victim must have been trying to access a plaintext http server= or the attacker has a compromised SSL/TLS certificate. For the IPFire situation then the OpenVPN server is restricted to the people = from the organisation that is running that IPFire instance. So the pool of at= tackers is much reduced, as is the pool of clients for the attacker to focus = on. However it still could occur in principle. The issue occurs due to the way that netfilter and its use in NAT has been bu= ilt. It is not a bug per se but an artefact of how it was built, if I underst= and it correctly. The paper has the following statement: "A comprehensive fix to this vulnerability would entail somehow modifying the= notions of garbage collection, connection direction, connection status, and simultaneous open in NAT impleme= ntations to be more consistent with the security and privacy requirements of VPNs." However the simplest mitigation seems to be to create a firewall rule for the= OpenVPN server that prevents the port the OpenVPN service is listening on fr= om being used as a source port by clients. This use of the same port is what = gives the Port Shadowing effect, allowing the de-anonymisation of a client. My conclusion is that it could happen with an OpenVPN server but the opportun= ity is restricted compared to commercial VPN providers. A fix is either for people to create this firewall rule themselves or we coul= d add it into the standard rules applied by IPFire unless that rule has other= consequences. It would be good to have Erik's or other peoples input to confirm that my int= erpretation of the material is correct but at least here is a first input on = this. Regards, Adolf. On 09/09/2021 22:41, Peter M=C3=BCller wrote: > Hello Erik, > hello *, > > https://www.openwall.com/lists/oss-security/2021/09/08/3 crossed my path th= e other day, > but I did not yet have time to read it comprehensively. > > Since you being the OpenVPN guru around here (no offense intended :-) ): Ar= e you aware > of this? Is this something we are affected by? > > Thanks, and best regards, > Peter M=C3=BCller --===============5049698309850004233==--