netdev - Re: [PATCH] netfilter: conntrack: tcp: do not lower timeout to CLOSE for in-window RSTs

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240710094554.483075-1-979093444@qq.com>
Date: Wed, 10 Jul 2024 17:45:54 +0800
From: yyxRoy <yyxroy22@...il.com>
To: fw@...len.de
Cc: 979093444@...com,
	coreteam@...filter.org,
	davem@...emloft.net,
	edumazet@...gle.com,
	gregkh@...uxfoundation.org,
	kadlec@...ckhole.kfki.hu,
	kuba@...nel.org,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org,
	pabeni@...hat.com,
	pablo@...filter.org,
	yyxroy22@...il.com
Subject: Re: [PATCH] netfilter: conntrack: tcp: do not lower timeout to CLOSE for in-window RSTs

On Mon, 8 Jul 2024 at 22:12, Florian Westphal <fw@...len.de> wrote:
> We can track TTL/NH.
> We can track TCP timestamps.
> 
> But how would we use such extra information?
> E.g. what I we observe:
> 
> ACK, TTL 32
> ACK, TTL 31
> ACK, TTL 30
> ACK, TTL 29
> 
> ... will we just refuse to update TTL?
> If we reduce it, any attacker can shrink it to needed low value
> to prevent later RST from reaching end host.
> 
> If we don't, connection could get stuck on legit route change?
> What about malicious entities injecting FIN/SYN packets rather than RST?
> 
> If we have last ts.echo from remote side, we can make it harder, but
> what do if RST doesn't carry timestamp?
> 
> Could be perfectly legal when machine lost state, e.g. power-cycled.
> So we can't ignore such RSTs.

I fully agree with your considerations. There are indeed some challenges with the proposed methods of enhancing checks on RSTs of in-window sequence numbers, TTL, and timestamps.

However, we now have known that conntrack may be vulnerable to attacks and illegal state transitions when it receives in-window RSTs with incorrect TTL or data packets + RSTs. Is it possible to find better methods to mitigate these issues, as they may pose threats to Netfilter users?

Note: We have also tested other connection tracking frameworks (such as FreeBSD/OpenBSD PF). Also playing the roles as middleboxes, they only change the state of the connection when they receive an RST with the currently known precise sequence number, thus avoiding these attacks. Could Netfilter adopt similar measures or else to further mitigate these issues?

Thank you again for your time and for your efforts in maintaining the community's performance and security!