linux-kernel - 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] [day] [month] [year] [list]

Message-ID: <7dd0aeaf-20cc-877c-e2d9-e0b40d40567d@blackhole.kfki.hu>
Date: Wed, 10 Jul 2024 15:49:24 +0200 (CEST)
From: Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
To: yyxRoy <yyxroy22@...il.com>
cc: Florian Westphal <fw@...len.de>, 979093444@...com, coreteam@...filter.org, 
    David Miller <davem@...emloft.net>, edumazet@...gle.com, 
    gregkh@...uxfoundation.org, kuba@...nel.org, linux-kernel@...r.kernel.org, 
    netdev@...r.kernel.org, netfilter-devel@...r.kernel.org, pabeni@...hat.com, 
    Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [PATCH] netfilter: conntrack: tcp: do not lower timeout to CLOSE
 for in-window RSTs

Hi,

On Wed, 10 Jul 2024, yyxRoy wrote:

> 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.

Your original suggestion was "Verify the sequence numbers of TCP packets 
strictly and do not change the timeout of the NAT mapping for an in-window 
RST packet." Please note, you should demonstrate that such a mitigation

- does not prevent (from conntrack point of view) currently
   handled/properly closed traffic to be handled with the mitigation as
   well
- the mitigation actually does not pose an easier exhaustion of the
   conntrack table, i.e. creating an easier DoS vulnerability against it.

> 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?

The attack requires exhaustive port scanning. That can be prevented with 
proper firewall rules.

> 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?

I find it really strange that those frameworks would match only the exact 
SEQ of the RST packets.

Best regards,
Jozsef
-- 
E-mail : kadlec@...filter.org, kadlec@...ckhole.kfki.hu, kadlecsik.jozsef@...ner.hu
Address: Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary