WireGuard / CVE-2019-14899: How secure the protocol really is?

Question

I've been using OpenVPN and SSH tunnels for a multitude of scenarios over the years and recently I've been earning a lot of buzz around the simplicity and security of WireGuard. Now I've found some troubling information about CVE-2019-14899:

An attacker that controls your L2 link (i.e., your WiFi or LAN) can send specially crafted packets to your device. The attacker can then use those packets to actively probe for certain properties of the TCP connections originating from your device. In other words, by controlling a device’s access point to the Internet, an attacker can infer if the user is connected to a specific host and port.

Additionally, if a TCP connection is unencrypted inside the VPN tunnel (if you visit a page that uses HTTP instead of HTTPS, for instance), the attacker can inject packets into that specific unencrypted stream. This would allow an attacker to feed your device fake HTML content for that particular stream. That would be dangerous, but as previously stated, the attacker must target a specific TCP connection, so it is not a simple vulnerability to exploit.

Source: https://protonvpn.com/blog/statement-on-cve-2019-14899/

1. Is this information technically correct?
2. Some sources on the web also state that anyone controlling the WAN of the server will also be able to take advantage of this flaw. Is it true? Can the server's ISP exploit this?

Assuming the information is correct:

3. Why does it matter if the "TCP connection is unencrypted inside the VPN tunnel"? In theory one uses a VPN exactly to go around this issue - to make sure nobody can see the contents of the communication between two machines;
4. If anyone controlling the client's LAN can inject packages, how is this even considered a secure protocol? From my understating authenticity validation is a must in scenarios like this. The server should be able to check the authenticity of new data instead of blindingly accepting it... Isn't there some kind of key exchange for this?
5. According to Wireguard's website "mimics the model of SSH and Mosh; both parties have each other's public keys, and then they're simply able to begin exchanging packets through the interface." How is a 3rd party (that doesn't have the right keys) able impersonate the client, send data and then how the server decrypts it using the client's real key without errors?

Thank you in advance.

Answer 1

Is this information technically correct?

Yes, but please note that there is a modification of the previous attack which cannot be stopped by the previously recommended mitigations - see Blind In/On-Path Attack Disclosure FAQ.

Some sources on the web also state that anyone controlling the WAN of the server will also be able to take advantage of this flaw. Is it true? Can the server's ISP exploit this?

This is a completely different scenario. The connection from VPN endpoint to server is not protected by the VPN anyway. If the attacker controls this part much easier and more dangerous attacks are possible.

Why does it matter if the "TCP connection is unencrypted inside the VPN tunnel"? In theory one uses a VPN exactly to go around this issue - to make sure nobody can see the contents of the communication between two machines

The attack is able to inject packets into an existing TCP connection. A normal TCP connection has only limited protection against this (i.e. random source port and sequence numbers) which are bypassed by the attack. If the connection is additionally protected by cryptography than this injection will no longer work. Note that "encryption" is actually neither required nor sufficient, but the point is integrity protection. But proper encryption protocols like TLS also include integrity protection.

If anyone controlling the client's LAN can inject packages, how is this even considered a secure protocol? From my understating authenticity validation is a must in scenarios like this. The server should be able to check the authenticity of new data instead of blindingly accepting it... Isn't there some kind of key exchange for this?

From the perspective of the server the data don't look wrong, i.e. nothing can be detected here.

According to Wireguard's website "mimics the model of SSH and Mosh; both parties have each other's public keys, and then they're simply able to begin exchanging packets through the interface." How is a 3rd party (that doesn't have the right keys) able impersonate the client, send data and then how the server decrypts it using the client's real key without errors?

This is not an attack against the encryption at all. The original attack CVE-2019-14899 worked by the client accepting plain data on a different interface and treating these the same way as the decrypted data from the VPN tunnel interface, thus making injection possible. That's why the attack is also independent of the actual layer 3 VPN technology used.

In other words: the OS (not the VPN) is merging trusted data coming out of the VPN interface (after decryption) with untrusted (attacker controlled) data coming from a different network interface. It is not an attack against the VPN layer itself but how the VPN is integrated into the OS.