lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <dd606a17-5fe1-4c04-b07c-e67b3c2e8223@openvpn.net>
Date: Thu, 18 Jul 2024 16:15:04 +0200
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
 Sergey Ryazanov <ryazanov.s.a@...il.com>, Paolo Abeni <pabeni@...hat.com>,
 Eric Dumazet <edumazet@...gle.com>, Andrew Lunn <andrew@...n.ch>,
 Esben Haabendal <esben@...nix.com>
Subject: Re: [PATCH net-next v3 10/24] ovpn: implement basic RX path (UDP)

On 18/07/2024 15:40, Sabrina Dubroca wrote:
> 2024-07-18, 15:27:42 +0200, Antonio Quartulli wrote:
>> On 18/07/2024 15:11, Sabrina Dubroca wrote:
>>>> basically the idea is: with our encapsulation we can guarantee that what
>>>> entered the tunnel is also exiting the tunnel, without corruption.
>>>> Therefore we claim that checksums are all correct.
>>>
>>> Can you be sure that they were correct when they went into the tunnel?
>>> If not, I think you have to set CHECKSUM_NONE.
>>
>> I can't be sure, because on the sender side we don't validate checksums
>> before encapsulation.
>>
>> If we assume that outgoing packets are always well formed and they can only
>> be damaged while traveling on the link, then the current code should be ok.
>>
>> If we cannot make this assumption, then we need the receiver to verify all
>> checksums before moving forward (which is what you are suggesting).
>>
>> Is it truly possible for the kernel to hand ovpn a packet with invalid
>> checksums on the TX path?
> 
> The networking stack shouldn't generate packets with broken checksums,
> but it could happen. On a VPN server that's giving access to an
> internal network, I think the packet could get corrupted on the
> internal network and may be pushed without verification into the
> tunnel.

Right.

In these cases the receiver would have a chance to detect and discard 
this packet.

With the current ovpn code, instead, we are saying "everything is good, 
don't check" and the packet would be delivered to the upper layer.

Ok, I think it makes sense to switch to CHECKSUM_NONE.

(I wonder what the wireguard guys think about it :-))

> 
> It's also possible to inject them with packet sockets for
> testing. Using scapy to send packets over your ovpn device should
> allow you to do that.

Thanks for the hint!

> 

-- 
Antonio Quartulli
OpenVPN Inc.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ