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: <CANn89iJmEgeRv5w+YwdOGf0bbS6hNRtYWQ860QGu=KMJqVKZAw@mail.gmail.com>
Date: Mon, 19 Aug 2024 11:18:07 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.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

On Mon, Aug 19, 2024 at 11:02 AM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> 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?

This will break some user programs, obviously.

I will ask you the opposite : What RFC prevents the current situation ?

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

Can you provide links to the issues ? How can a programmer hit this
using standard and documented ways (passive, active flows) ?

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