netdev - Re: [PATCH net-next] tcp: do not allow to connect with the four-tuple symmetry socket

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: <CAL+tcoAEGcaEdCjxs9_nM7ux_r8tuYhjsMtJZfemHQ+DLVqUYQ@mail.gmail.com>
Date: Mon, 19 Aug 2024 17:01:27 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>, 0x7f454c46@...il.com, davem@...emloft.net, 
	dima@...sta.com, dsahern@...nel.org, kernelxing@...cent.com, kuba@...nel.org, 
	ncardwell@...gle.com, netdev@...r.kernel.org, pabeni@...hat.com, 
	Florian Westphal <fw@...len.de>, Pablo Neira Ayuso <pablo@...filter.org>
Subject: Re: [PATCH net-next] tcp: do not allow to connect with the four-tuple
 symmetry socket

Hello Eric,

On Mon, Aug 19, 2024 at 3:30 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Mon, Aug 19, 2024 at 2:27 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > On Mon, Aug 19, 2024 at 7:48 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > >
> > > Hello Kuniyuki,
> > >
> > > On Mon, Aug 19, 2024 at 2:49 AM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> > > >
> > > > From: Jason Xing <kerneljasonxing@...il.com>
> > > > Date: Sun, 18 Aug 2024 21:50:51 +0800
> > > > > On Sun, Aug 18, 2024 at 1:16 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > > >
> > > > > > On Sun, Aug 18, 2024 at 12:25 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > > > >
> > > > > > > From: Jason Xing <kernelxing@...cent.com>
> > > > > > >
> > > > > > > Four-tuple symmetry here means the socket has the same remote/local
> > > > > > > port and ipaddr, like this, 127.0.0.1:8000 -> 127.0.0.1:8000.
> > > > > > > $ ss -nat | grep 8000
> > > > > > > ESTAB      0      0          127.0.0.1:8000       127.0.0.1:8000
> > > > >
> > > > > Thanks to the failed tests appearing in patchwork, now I'm aware of
> > > > > the technical term called "self-connection" in English to describe
> > > > > this case. I will update accordingly the title, body messages,
> > > > > function name by introducing "self-connection" words like this in the
> > > > > next submission.
> > > > >
> > > > > Following this clue, I saw many reports happening in these years, like
> > > > > [1][2]. Users are often astonished about this phenomenon and lost and
> > > > > have to find various ways to workaround it. Since, in my opinion, the
> > > > > self-connection doesn't have any advantage and usefulness,
> > > >
> > > > It's useful if you want to test simultaneous connect (SYN_SENT -> SYN_RECV)
> > > > path as you see in TCP-AO tests.  See RFC 9293 and the (!ack && syn) case
> > > > in tcp_rcv_synsent_state_process().
> > > >
> > > >   https://www.rfc-editor.org/rfc/rfc9293.html#section-3.5-7
> > >
> > > Yes, I noticed this one: self-connection is one particular case among
> > > simultaneously open cases. Honestly, it's really strange that client
> > > and server uses a single socket.
> > >
> > > >
> > > > So you can't remove self-connect functionality, the recent main user is
> > > > syzkaller though.
> > >
> > > Ah, thanks for reminding me. It seems that I have to drop this patch
> > > and there is no good way to resolve the issue in the kernel.
> > >
> >
> > Can we introduce one sysctl knob to control it since we can tell there
> > are many user reports/complaints through the internet? Default setting
> > of the new knob is to allow users to connect to itself like right now,
> > not interfering with many years of habits, like what the test tools
> > currently use.
> >
> > Can I give it a shot?
>
> No you can not.

May I ask why? Is it because self-connection adheres to the
simultaneously open part in RFC 9293?

I feel this case is very particular, not explained well in the RFC.
Usually, we don't consider one socket to act as client and server
unless in debug or test circumstances. As you can see, some people
have encountered the issue for a long time.

>
> netfilter can probably do this.

Sure, It can do. It can be a little bit helpful, but clumsy. We have
to set specific rules for each possible listener and then drop those
SYN packets if they carry the same remote and local port/ip.

Thanks,
Jason