netdev - Re: [PATCH] document danger of '-j REJECT'ing of '-m state INVALID' packets

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]

Date:   Sat, 9 May 2020 12:52:59 +0200 (CEST)
From:   Jan Engelhardt <jengelh@...i.de>
To:     Maciej Żenczykowski <zenczykowski@...il.com>
cc:     Maciej Żenczykowski <maze@...gle.com>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Florian Westphal <fw@...len.de>,
        Linux Network Development Mailing List 
        <netdev@...r.kernel.org>,
        Netfilter Development Mailing List 
        <netfilter-devel@...r.kernel.org>
Subject: Re: [PATCH] document danger of '-j REJECT'ing of '-m state INVALID'
 packets

On Saturday 2020-05-09 07:22, Maciej Żenczykowski wrote:
>diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_REJECT.man
>index 0030a51f..b6474811 100644
>--- a/extensions/libip6t_REJECT.man
>+++ b/extensions/libip6t_REJECT.man
>@@ -30,3 +30,18 @@ TCP RST packet to be sent back.  This is mainly useful for blocking
> hosts (which won't accept your mail otherwise).
> \fBtcp\-reset\fP
> can only be used with kernel versions 2.6.14 or later.
>+.PP
>+\fIWarning:\fP if you are using connection tracking and \fBACCEPT\fP'ing
>+\fBESTABLISHED\fP (and possibly \fBRELATED\fP) state packets, do not
>+indiscriminately \fBREJECT\fP (especially with \fITCP RST\fP) \fBINVALID\fP
>+state packets.  Sometimes naturally occuring packet reordering will result
>+in packets being considered \fBINVALID\fP and the generated \fITCP RST\fP
>+will abort an otherwise healthy connection.

I fail to understand the problem here.

1. Because ESTABLISHED and INVALID are mutually exclusive, there is no ordering
dependency between two rules of the kind {EST=>ACCEPT, INV=>REJ},
and thus their order plays no role.

2. Given packets D,R (data, rst) leads to state(ct(D))=EST, state(ct(R))=EST in
the normal case. When this gets reordered to R,D, then we end up with
state(ct(R))=EST, state(ct(D))=INV. Though the outcome of nfct changes,
I do not think that will be of consequence, because in the absence of
filtering, the tcp layer should be discarding/rejecting D.

3. Natural reordering of D1,D2 to D2,D1 should not cause nfct to drop the ct
at reception of D1 and turn the state to INV. Reordering can happen at any
time, and we'd be having more reports of problems if it did, wouldn't we...