[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfire-development
Subject:    Re: Fwd: [oss-security] CVE-2021-3773: Lack of port sanity checking in natd and Netfilter leads to e
From:       Adolf Belka <adolf.belka () ipfire ! org>
Date:       2021-09-27 11:08:52
Message-ID: 8a0c2f9b-109e-eb47-2730-cca875767f0f () ipfire ! org
[Download RAW message or body]

Hi Peter,

I am definitely not in Erik's class in terms of OpenVPN understanding but I have 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 \
providers. 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 that uses \
the Port Shadowing issue that has been identified to de-anonymise the victim. Then \
with this information the attacker can set up an OpenVPN Client to man in the middle \
attack. With this they then can use a recently disclosed 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 attackers 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 built. It \
is not a bug per se but an artefact of how it was built, if I understand 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 implementations 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 from 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 opportunity is \
restricted compared to commercial VPN providers.

A fix is either for people to create this firewall rule themselves or we could 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 \
interpretation 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üller wrote:
> Hello Erik,
> hello *,
> 
> https://www.openwall.com/lists/oss-security/2021/09/08/3 crossed my path the other \
> day, but I did not yet have time to read it comprehensively.
> 
> Since you being the OpenVPN guru around here (no offense intended :-) ): Are you \
> aware of this? Is this something we are affected by?
> 
> Thanks, and best regards,
> Peter Müller


[prev in list] [next in list] [prev in thread] [next in thread]