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

Powered by blists - more mailing lists