[PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

Hi David,

well, I could easily build a proof of concept demonstrating the security
problem implied by the simultaneous connect support. For this, I have two
machines on the LAN. One (wks, 10.0.3.9, 2.4.29) wants to connect to
www.kernel.org:80 (204.152.191.5). It works as expected :

  wks:willy$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
  HTTP/1.1 200 OK
  Date: Sat, 11 Jun 2005 07:08:27 GMT
  Server: Apache/2.0.52 (Fedora)
  Accept-Ranges: bytes
  Connection: close
  Content-Type: text/html

  ret=0

The other one (pcw) tries to prevent wks from connecting to www.kernel.org,
by sending to it about 10 SYNs per second spoofing kernel.org's port 80 :
  pcw# hping2 -i u100000 -k -a 204.152.191.5 -s 80 -I eth0 10.0.3.9 -p 10000 -S -M 12345678

During this, the client cannot connect to www.kernel.org from this port
anymore :
  wks$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
  ret=1

Capture on the victim (wks=victim, pcw=attacker, www=www.kernel.org):

  wks 09:06:44.020809 10.0.3.9.10000 > 204.152.191.5.80: S 4010109823:4010109823(0) win 5840 <mss 1460,nop,wscale 0> (DF)
  pcw 09:06:44.065589 204.152.191.5.80 > 10.0.3.9.10000: S 12345678:12345678(0) win 512
  wks 09:06:44.065621 10.0.3.9.10000 > 204.152.191.5.80: S 4010109823:4010109823(0) ack 12345679 win 5840 <mss 1460,nop,wscale 0> (DF)
  pcw 09:06:44.166544 204.152.191.5.80 > 10.0.3.9.10000: S 12345678:12345678(0) win 512
  www 09:06:44.217896 204.152.191.5.80 > 10.0.3.9.10000: S 2774672577:2774672577(0) ack 4010109824 win 5840 <mss 1420,nop,wscale 2> (DF)
  wks 09:06:44.217939 10.0.3.9.10000 > 204.152.191.5.80: . ack 12345679 win 5840 (DF)
  wks 09:06:47.020040 10.0.3.9.10000 > 204.152.191.5.80: S 4010109823:4010109823(0) ack 12345679 win 5840 <mss 1460,nop,wscale 0> (DF)
  ...

=> cannot establish, because of either my local firewall or www.kernel.org's
blocks wrong ACKs. Without a firewall, wks would have got an RST.

With the attached patch, I can no longer block the communication :

  09:31:23.004379 IP (tos 0x0, ttl  64, id 36202, offset 0, flags [DF], length: 60) 10.0.3.1.10000 > 204.152.191.5.80: S [tcp sum ok] 1176290222:1176290222(0) win 13920 <mss 6960,sackOK,timestamp 4294921924 0,nop,wscale 2>
  09:31:23.051743 IP (tos 0x0, ttl  64, id 9074, offset 0, flags [none], length: 40) 204.152.191.5.80 > 10.0.3.1.10000: S [tcp sum ok] 12345678:12345678(0) win 512
  09:31:23.102683 IP (tos 0x0, ttl  64, id 42364, offset 0, flags [none], length: 40) 204.152.191.5.80 > 10.0.3.1.10000: S [tcp sum ok] 12345678:12345678(0) win 512
  09:31:23.203546 IP (tos 0x0, ttl  58, id 0, offset 0, flags [DF], length: 60) 204.152.191.5.80 > 10.0.3.1.10000: S [tcp sum ok] 3923636405:3923636405(0) ack 1176290223 win 5792 <mss 1420,sackOK,timestamp 2199155996 4294921924,nop,wscale 2>
  09:31:23.203625 IP (tos 0x0, ttl  64, id 36204, offset 0, flags [DF], length: 52) 10.0.3.1.10000 > 204.152.191.5.80: . [tcp sum ok] 1176290223:1176290223(0) ack 3923636406 win 3480 <nop,nop,timestamp 4294922124 2199155996>

=> the client ignores fake SYNs and the connection establishes normally.

The proposed patch adds a "tcp_simult_connect "sysctl which is disabled by
default to fix the problem for non-aware people. Those who know they need
the simultaneous connect can enable it manually, but I doubt we can find
many of them.

Does it seem appropriate for mainline ? In this case, I would also backport
it to 2.4 and send it to you for inclusion.

Thanks,
Willy


diff -urN linux-2.6.11.11/include/linux/sysctl.h linux-2.6.11.11-tcp/include/linux/sysctl.h
--- linux-2.6.11.11/include/linux/sysctl.h	Mon Mar 28 07:06:45 2005
+++ linux-2.6.11.11-tcp/include/linux/sysctl.h	Sat Jun 11 09:00:22 2005
@@ -345,6 +345,7 @@
 	NET_TCP_MODERATE_RCVBUF=106,
 	NET_TCP_TSO_WIN_DIVISOR=107,
 	NET_TCP_BIC_BETA=108,
+	NET_TCP_SIMULT_CONNECT=109,
 };
 
 enum {
diff -urN linux-2.6.11.11/include/net/tcp.h linux-2.6.11.11-tcp/include/net/tcp.h
--- linux-2.6.11.11/include/net/tcp.h	Mon Mar 28 07:06:45 2005
+++ linux-2.6.11.11-tcp/include/net/tcp.h	Sat Jun 11 08:56:16 2005
@@ -608,6 +608,7 @@
 extern int sysctl_tcp_bic_beta;
 extern int sysctl_tcp_moderate_rcvbuf;
 extern int sysctl_tcp_tso_win_divisor;
+extern int sysctl_tcp_simult_connect;
 
 extern atomic_t tcp_memory_allocated;
 extern atomic_t tcp_sockets_allocated;
diff -urN linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c
--- linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c	Mon Mar 28 07:06:48 2005
+++ linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c	Sat Jun 11 08:55:27 2005
@@ -690,6 +690,14 @@
 		.mode		= 0644,
 		.proc_handler	= &proc_dointvec,
 	},
+	{
+		.ctl_name	= NET_TCP_SIMULT_CONNECT,
+		.procname	= "tcp_simult_connect",
+		.data		= &sysctl_tcp_simult_connect,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
 	{ .ctl_name = 0 }
 };
 
diff -urN linux-2.6.11.11/net/ipv4/tcp_input.c linux-2.6.11.11-tcp/net/ipv4/tcp_input.c
--- linux-2.6.11.11/net/ipv4/tcp_input.c	Fri Jun 10 22:49:43 2005
+++ linux-2.6.11.11-tcp/net/ipv4/tcp_input.c	Sat Jun 11 08:58:54 2005
@@ -84,6 +84,7 @@
 
 int sysctl_tcp_stdurg;
 int sysctl_tcp_rfc1337;
+int sysctl_tcp_simult_connect;
 int sysctl_tcp_max_orphans = NR_FILE;
 int sysctl_tcp_frto;
 int sysctl_tcp_nometrics_save;
@@ -4620,7 +4621,7 @@
 	if (tp->rx_opt.ts_recent_stamp && tp->rx_opt.saw_tstamp && tcp_paws_check(&tp->rx_opt, 0))
 		goto discard_and_undo;
 
-	if (th->syn) {
+	if (th->syn && sysctl_tcp_simult_connect) {
 		/* We see SYN without ACK. It is attempt of
 		 * simultaneous connect with crossed SYNs.
 		 * Particularly, it can be connect to self.

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

Willy Tarreau <willy@w.ods.org> wrote:
> 
> During this, the client cannot connect to www.kernel.org from this port
> anymore :
>  wks$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
>  ret=1

What if you let the client connect from a random port which is what it
should do?
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

Hi Herbert,

On Sun, Jun 12, 2005 at 05:32:34AM +1000, Herbert Xu wrote:
> Willy Tarreau <willy@w.ods.org> wrote:
> > 
> > During this, the client cannot connect to www.kernel.org from this port
> > anymore :
> >  wks$ printf "HEAD / HTTP/1.0\r\n\r\n" | nc -p 10000 204.152.191.5 80; echo "ret=$?"
> >  ret=1
> 
> What if you let the client connect from a random port which is what it
> should do?

Of course, if the port chosen by the client is not in the range probed by
the attacker, everything's OK. My point is that relying *only* on a port
number is a bit limitative. It is even more when some protocols only bind
to privileged source ports, or always use the same port range at boot (eg:
a router establishing a BGP connection to the ISP's router).

Please note that if I only called it "small DoS", it's clearly because
I don't consider this critical, but I think that most people involved
in security will find that DoSes based on port guessing should be
addressed when possible.

Regards,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sat, Jun 11, 2005 at 09:51:44PM +0200, Willy Tarreau wrote:
> 
> Please note that if I only called it "small DoS", it's clearly because
> I don't consider this critical, but I think that most people involved
> in security will find that DoSes based on port guessing should be
> addressed when possible.

Sorry but this patch is pointless.  If I wanted to prevent you from
connecting to www.kernel.org 80 and I knew your source port number
I'd be directly sending you fake SYN-ACK packets which will kill
your connection immediately.

If you want reliability and security you really should be using IPsec.
There is no other way.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 06:13:27PM +1000, Herbert Xu wrote:
> On Sat, Jun 11, 2005 at 09:51:44PM +0200, Willy Tarreau wrote:
> > 
> > Please note that if I only called it "small DoS", it's clearly because
> > I don't consider this critical, but I think that most people involved
> > in security will find that DoSes based on port guessing should be
> > addressed when possible.
> 
> Sorry but this patch is pointless.  If I wanted to prevent you from
> connecting to www.kernel.org 80 and I knew your source port number
> I'd be directly sending you fake SYN-ACK packets which will kill
> your connection immediately.

Only if your ACK was within my SEQ window, which adds about 20 bits of
random when my initial window is 5840. You would then need to send one
million times more packets to achieve the same goal.

> If you want reliability and security you really should be using IPsec.
> There is no other way.

I agree with you on the fact that people who need security must use
secure protocols. I had the same words last year when people discovered
that a TCP RST could kill a BGP session, and the end of the internet was
announced. Hey, if someone needs secure BGP, he must use MD5 sums from
the start.

I'm not meaning to make TCP as secure as IPsec, but I think that when
supporting a feature (simultaneous connect) that nobody uses and many
OSes do not even support introduces a weakness, we could at least make
it optional. It could also rely on a #if CONFIG_TCP_SIMULT which will
slightly reduce kernel size for people who know they don't want it.

Cheers,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sun, Jun 12, 2005 at 10:34:09AM +0200, Willy Tarreau wrote:
>
> > Sorry but this patch is pointless.  If I wanted to prevent you from
> > connecting to www.kernel.org 80 and I knew your source port number
> > I'd be directly sending you fake SYN-ACK packets which will kill
> > your connection immediately.
> 
> Only if your ACK was within my SEQ window, which adds about 20 bits of
> random when my initial window is 5840. You would then need to send one
> million times more packets to achieve the same goal.

Nope, no sequence validity check is made on the SYN-ACK.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 08:30:20PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 10:34:09AM +0200, Willy Tarreau wrote:
> >
> > > Sorry but this patch is pointless.  If I wanted to prevent you from
> > > connecting to www.kernel.org 80 and I knew your source port number
> > > I'd be directly sending you fake SYN-ACK packets which will kill
> > > your connection immediately.
> > 
> > Only if your ACK was within my SEQ window, which adds about 20 bits of
> > random when my initial window is 5840. You would then need to send one
> > million times more packets to achieve the same goal.
> 
> Nope, no sequence validity check is made on the SYN-ACK.

Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
with this statement. Look: at line 5, A rejects the SYN-ACK because the
ACK is wrong during the session setup.

And if you send the SYN-ACK on an established session, either it's in the
window in which case the other end will send an RST, or it's outside the
window, in which case the other end will resend an ACK to tell you what
it expects. So I maintain my statement that the SYN-ACK must be within the
window to cause a session reset. That's why I considered cisco's approach
a total bullshit, because they mangled the TCP implementation to protect
against in-window RSTs, but they failed to see that SYN-ACK would do exactly
the same.

I fail to find a case where both the SEQ and the ACK are ignored. This
is why I believe that the simultaneous connect mode introduces a weakness.

Cheers,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sun, Jun 12, 2005 at 01:40:39PM +0200, Willy Tarreau wrote:
>
> Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
> with this statement. Look: at line 5, A rejects the SYN-ACK because the
> ACK is wrong during the session setup.

Look at the first check inside th->ack in tcp_rcv_synsent_state_process.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Thomas Graf]

* Herbert Xu <20050612120627.GA5858@gondor.apana.org.au> 2005-06-12 22:06
> On Sun, Jun 12, 2005 at 01:40:39PM +0200, Willy Tarreau wrote:
> >
> > Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
> > with this statement. Look: at line 5, A rejects the SYN-ACK because the
> > ACK is wrong during the session setup.
> 
> Look at the first check inside th->ack in tcp_rcv_synsent_state_process.

Usually a continious flow of ACK+RST is used to prevent a connection
from being established, it's more reliable because even if you hit the
ISS+rcv_next window the connection attempt will still be reset.

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 10:06:27PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 01:40:39PM +0200, Willy Tarreau wrote:
> >
> > Sorry Herbert, but both RFC793 page 32 figure 9 and my Linux box disagree
> > with this statement. Look: at line 5, A rejects the SYN-ACK because the
> > ACK is wrong during the session setup.
> 
> Look at the first check inside th->ack in tcp_rcv_synsent_state_process.

Herbert, I perfectly agree with this check and it's consistent with what I
observe. But as you know, there's a difference between resetting a session
and sending an RST to say that we refuse a segment. This check does not kill
the session, it sends an RST whose SEQ is equal to the SYN-ACK's ACK. It's
possible you though the "reset_and_undo" label was used to kill the session,
but it's not the case (although the naming is not clear). So if the remote
end was the one which sent the SYN-ACK, it will clear its session. If it has
been spoofed, it will ignore the RST because in turn, the SEQ will not be
within its window.

Try it by yourself if you don't believe me. I've done lots of tests with
hping2 and I've never managed to kill a session with both a SEQ and ACK
outside the windows.

Regards,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
>
> but it's not the case (although the naming is not clear). So if the remote
> end was the one which sent the SYN-ACK, it will clear its session. If it has
> been spoofed, it will ignore the RST because in turn, the SEQ will not be
> within its window.

This is what should happen:

1) client A sends SYN to server B.
2) attcker C sends spoofed SYN-ACK to client A purporting to be server B.
3) client A sends RST to server B.

The RST packet is sent by client A using its sequence numbers.  Therefore
it will pass the sequence number check on server B.

4) server B resets the connection.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sun, Jun 12, 2005 at 02:22:47PM +0200, Thomas Graf wrote:
>
> > Look at the first check inside th->ack in tcp_rcv_synsent_state_process.
> 
> Usually a continious flow of ACK+RST is used to prevent a connection
> from being established, it's more reliable because even if you hit the
> ISS+rcv_next window the connection attempt will still be reset.

Sure.  My point is that there are a hundred and one ways to attack
a TCP connection in a manner similar to the original method that
started this thread.  So fixes like this are pretty pointless.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sun, Jun 12, 2005 at 11:13:23PM +1000, herbert wrote:
> On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
> >
> > but it's not the case (although the naming is not clear). So if the remote
> > end was the one which sent the SYN-ACK, it will clear its session. If it has
> > been spoofed, it will ignore the RST because in turn, the SEQ will not be
> > within its window.
> 
> This is what should happen:

Sorry, you're right.  The SEQ check should catch this.

However, a few lines down in that same function there is a th->rst
check which will kill the connection just as effectively.

My point is that there are many ways to kill TCP connections in ways
similar to what you proposed initially so it isn't that special.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 11:13:23PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
> >
> > but it's not the case (although the naming is not clear). So if the remote
> > end was the one which sent the SYN-ACK, it will clear its session. If it has
> > been spoofed, it will ignore the RST because in turn, the SEQ will not be
> > within its window.
> 
> This is what should happen:
> 
> 1) client A sends SYN to server B.
> 2) attcker C sends spoofed SYN-ACK to client A purporting to be server B.
> 3) client A sends RST to server B.

Agreed till here.

> The RST packet is sent by client A using its sequence numbers.  Therefore
> it will pass the sequence number check on server B.
>
> 4) server B resets the connection.

No, precisely the RST sent by A will take its SEQ from C's ACK number.
This is why B will *not* reset the connection (again, tested) if C's ACK
was not within B's window.

Cheers,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 11:33:49PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 11:13:23PM +1000, herbert wrote:
> > On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
> > >
> > > but it's not the case (although the naming is not clear). So if the remote
> > > end was the one which sent the SYN-ACK, it will clear its session. If it has
> > > been spoofed, it will ignore the RST because in turn, the SEQ will not be
> > > within its window.
> > 
> > This is what should happen:
> 
> Sorry, you're right.  The SEQ check should catch this.

No problem. Fortunately, this part of the code is *very well* documented :-)

> However, a few lines down in that same function there is a th->rst
> check which will kill the connection just as effectively.

Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
so the connection will survive.

> My point is that there are many ways to kill TCP connections in ways
> similar to what you proposed initially so it isn't that special.

No, there are plenty of ways to kill TCP connections when you can guess
the window (which is more and more easy thanks to window scaling). But
I have yet found no way to kill a TCP session without this info, except
by exploiting the simultaneous connect feature.

My point was that it would not be too difficult to remotely prevent an
anti-virus or IDS from downloading its updates when you know the update
site's address and you know that by default it uses source ports
1024-4999 to connect outside. I don't really care for BGP however
because people should use MD5 or they get what they deserve.

Cheers,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sun, Jun 12, 2005 at 03:47:25PM +0200, Willy Tarreau wrote:
> 
> Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
> so the connection will survive.

Sorry I wasn't thinking straight.

> 
> > My point is that there are many ways to kill TCP connections in ways
> > similar to what you proposed initially so it isn't that special.
> 
> No, there are plenty of ways to kill TCP connections when you can guess
> the window (which is more and more easy thanks to window scaling). But
> I have yet found no way to kill a TCP session without this info, except
> by exploiting the simultaneous connect feature.

I still stand by this point though.  The most obvious thing I can think
of right now is to change your attack to simply connect to kernel.org's
webserver first from source port 10000.  That will cause the real SYN
packet to fail the sequence number check.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 11:50:18PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 03:47:25PM +0200, Willy Tarreau wrote:
> > 
> > Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
> > so the connection will survive.
> 
> Sorry I wasn't thinking straight.
> 
> > 
> > > My point is that there are many ways to kill TCP connections in ways
> > > similar to what you proposed initially so it isn't that special.
> > 
> > No, there are plenty of ways to kill TCP connections when you can guess
> > the window (which is more and more easy thanks to window scaling). But
> > I have yet found no way to kill a TCP session without this info, except
> > by exploiting the simultaneous connect feature.
> 
> I still stand by this point though.  The most obvious thing I can think
> of right now is to change your attack to simply connect to kernel.org's
> webserver first from source port 10000.  That will cause the real SYN
> packet to fail the sequence number check.

This case is interesting, but it will be resolved in two possible ways :
1) no firewall in front of A
  - C spoofs A and sends a fake SYN to B
  - B responds to A with a SYN-ACK
  - A sends an RST to B, which clears the session
  - A wants to connect and sends its SYN to B which accepts it.

2) A behind a firewall
  - C spoofs A and sends a fake SYN to B
  - B responds to A with a SYN-ACK, which does not reach A (firewall, etc...)
  - A tries to connect to B and sends its SYN with a different SEQ
  - B responds to A with only an ACK (no SYN) indicating the expected SEQ.
  - A responds to B's ACK with an RST and B flushes its session too.
  - A resends its SYN to B which accepts it.
 
Cheers,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Thomas Graf]

* Willy Tarreau <20050612133654.GA8951@alpha.home.local> 2005-06-12 15:36
> > The RST packet is sent by client A using its sequence numbers.  Therefore
> > it will pass the sequence number check on server B.
> >
> > 4) server B resets the connection.
> 
> No, precisely the RST sent by A will take its SEQ from C's ACK number.
> This is why B will *not* reset the connection (again, tested) if C's ACK
> was not within B's window.

Absolutely but it relies on the other stack being correctly implemented.
The attack would work perfectly fine if there wasn't the rule that a RST
must not be sent in response to another RST. The attack has been
successful and still is because some firewalls are configured to send
RSTs without respecting this rule.

I like your patch and the idea behind it, it can successfully defeat the
most simple method of preventing connections being established.

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 04:44:26PM +0200, Thomas Graf wrote:
> * Willy Tarreau <20050612133654.GA8951@alpha.home.local> 2005-06-12 15:36
> > > The RST packet is sent by client A using its sequence numbers.  Therefore
> > > it will pass the sequence number check on server B.
> > >
> > > 4) server B resets the connection.
> > 
> > No, precisely the RST sent by A will take its SEQ from C's ACK number.
> > This is why B will *not* reset the connection (again, tested) if C's ACK
> > was not within B's window.
> 
> Absolutely but it relies on the other stack being correctly implemented.
> The attack would work perfectly fine if there wasn't the rule that a RST
> must not be sent in response to another RST.

Of course, if you target a buggy stack, you can expect anything.

> The attack has been successful and still is because some firewalls
> are configured to send RSTs without respecting this rule.

In fact, I voluntarily did not speak about firewalls because almost all
of them are very sensible to TCP DoSes. First of all, all those which
don't check sequence numbers will blindly kill a session when they
receive an RST. And some of the other ones will not let certain ACK
packets pass through, which will make other DoS described in this
thread effective while it should not be, by not letting the server
tell the client to reset its session when really needed.

> I like your patch and the idea behind it, it can successfully defeat the
> most simple method of preventing connections being established.

That's what I thought, too. I have another one for 2.4.31 which only adds
a CONFIG option to remove the associated code, which reduces the image by
400 bytes.

Cheers,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Denis Vlasenko]

> Does it seem appropriate for mainline ? In this case, I would also backport
> it to 2.4 and send it to you for inclusion.

It does not contain a comment why it is configurable.
--
vda

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 08:10:33PM +0300, Denis Vlasenko wrote:
> > Does it seem appropriate for mainline ? In this case, I would also backport
> > it to 2.4 and send it to you for inclusion.
> 
> It does not contain a comment why it is configurable.

You're right. Better with this ?

Willy
--

diff -pruNX dontdiff linux-2.6.11.11/Documentation/networking/ip-sysctl.txt linux-2.6.11.11-tcp/Documentation/networking/ip-sysctl.txt
--- linux-2.6.11.11/Documentation/networking/ip-sysctl.txt	Sun Mar  6 13:08:46 2005
+++ linux-2.6.11.11-tcp/Documentation/networking/ip-sysctl.txt	Sun Jun 12 19:28:50 2005
@@ -368,6 +368,27 @@ tcp_frto - BOOLEAN
 	where packet loss is typically due to random radio interference
 	rather than intermediate router congestion.
 
+tcp_simult_connect - BOOLEAN
+	Enables TCP simultaneous connect feature conforming to RFC793.
+	Strict implementation of RFC793 (TCP) requires support for a feature
+	called "simultaneous connect", which allows two clients to connect to
+	each other without anyone entering a listening state.  While almost
+	never used, and supported by few OSes, Linux supports this feature.
+
+	However, it introduces a weakness in the protocol which makes it very
+	easy for an attacker to prevent a client from connecting to a known
+	server. The attacker only has to guess the source port to shut down
+	the client connection during its establishment. The impact is limited,
+	but it may be used to prevent an antivirus or IPS from fetching updates
+	and not detecting an attack, or to prevent an SSL gateway from fetching
+	a CRL for example.
+
+	If you want backwards compatibility with every possible application,
+	you should set it to 1. If you prefer to enhance security on your
+	systems at the risk of breaking very rare specific applications, you'd
+	better let it to 0.
+	Default: 0
+
 somaxconn - INTEGER
 	Limit of socket listen() backlog, known in userspace as SOMAXCONN.
 	Defaults to 128.  See also tcp_max_syn_backlog for additional tuning
diff -pruNX dontdiff linux-2.6.11.11/include/linux/sysctl.h linux-2.6.11.11-tcp/include/linux/sysctl.h
--- linux-2.6.11.11/include/linux/sysctl.h	Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/include/linux/sysctl.h	Sat Jun 11 09:00:22 2005
@@ -345,6 +345,7 @@ enum
 	NET_TCP_MODERATE_RCVBUF=106,
 	NET_TCP_TSO_WIN_DIVISOR=107,
 	NET_TCP_BIC_BETA=108,
+	NET_TCP_SIMULT_CONNECT=109,
 };
 
 enum {
diff -pruNX dontdiff linux-2.6.11.11/include/net/tcp.h linux-2.6.11.11-tcp/include/net/tcp.h
--- linux-2.6.11.11/include/net/tcp.h	Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/include/net/tcp.h	Sat Jun 11 08:56:16 2005
@@ -608,6 +608,7 @@ extern int sysctl_tcp_bic_low_window;
 extern int sysctl_tcp_bic_beta;
 extern int sysctl_tcp_moderate_rcvbuf;
 extern int sysctl_tcp_tso_win_divisor;
+extern int sysctl_tcp_simult_connect;
 
 extern atomic_t tcp_memory_allocated;
 extern atomic_t tcp_sockets_allocated;
diff -pruNX dontdiff linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c
--- linux-2.6.11.11/net/ipv4/sysctl_net_ipv4.c	Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/net/ipv4/sysctl_net_ipv4.c	Sat Jun 11 08:55:27 2005
@@ -690,6 +690,14 @@ ctl_table ipv4_table[] = {
 		.mode		= 0644,
 		.proc_handler	= &proc_dointvec,
 	},
+	{
+		.ctl_name	= NET_TCP_SIMULT_CONNECT,
+		.procname	= "tcp_simult_connect",
+		.data		= &sysctl_tcp_simult_connect,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
 	{ .ctl_name = 0 }
 };
 
diff -pruNX dontdiff linux-2.6.11.11/net/ipv4/tcp_input.c linux-2.6.11.11-tcp/net/ipv4/tcp_input.c
--- linux-2.6.11.11/net/ipv4/tcp_input.c	Sun Jun 12 10:44:01 2005
+++ linux-2.6.11.11-tcp/net/ipv4/tcp_input.c	Sun Jun 12 19:33:56 2005
@@ -84,6 +84,7 @@ int sysctl_tcp_adv_win_scale = 2;
 
 int sysctl_tcp_stdurg;
 int sysctl_tcp_rfc1337;
+int sysctl_tcp_simult_connect;
 int sysctl_tcp_max_orphans = NR_FILE;
 int sysctl_tcp_frto;
 int sysctl_tcp_nometrics_save;
@@ -4620,10 +4621,12 @@ discard:
 	if (tp->rx_opt.ts_recent_stamp && tp->rx_opt.saw_tstamp && tcp_paws_check(&tp->rx_opt, 0))
 		goto discard_and_undo;
 
-	if (th->syn) {
+	if (th->syn && sysctl_tcp_simult_connect) {
 		/* We see SYN without ACK. It is attempt of
 		 * simultaneous connect with crossed SYNs.
 		 * Particularly, it can be connect to self.
+		 * This feature is disabled by default as it introduces a
+		 * weakness in the protocol. It can be enabled by a sysctl.
 		 */
 		tcp_set_state(sk, TCP_SYN_RECV);
 

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Denis Vlasenko]

On Sunday 12 June 2005 20:36, Willy Tarreau wrote:
> On Sun, Jun 12, 2005 at 08:10:33PM +0300, Denis Vlasenko wrote:
> > > Does it seem appropriate for mainline ? In this case, I would also backport
> > > it to 2.4 and send it to you for inclusion.
> > 
> > It does not contain a comment why it is configurable.
> 
> You're right. Better with this ?

Very nice. BTW, is there any real world applications which
ever used this?

> +	If you want backwards compatibility with every possible application,
> +	you should set it to 1. If you prefer to enhance security on your
> +	systems at the risk of breaking very rare specific applications, you'd
> +	better let it to 0.
> +	Default: 0

This text leaves an impression that they exist.
--
vda

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Sun, Jun 12, 2005 at 08:47:07PM +0300, Denis Vlasenko wrote:
> On Sunday 12 June 2005 20:36, Willy Tarreau wrote:
> > On Sun, Jun 12, 2005 at 08:10:33PM +0300, Denis Vlasenko wrote:
> > > > Does it seem appropriate for mainline ? In this case, I would also backport
> > > > it to 2.4 and send it to you for inclusion.
> > > 
> > > It does not contain a comment why it is configurable.
> > 
> > You're right. Better with this ?
> 
> Very nice. BTW, is there any real world applications which
> ever used this?

Not that I'm aware of, but that does not mean they don't exist. Until
yesterday, I even thought that it was never implemented. As most other
systems don't implement it, the applications, if they exist, are Linux
or BSD-dependant. It's even difficult to use because the two ends must
loop around the connect() call until it succeeds, because as long as
they're not both trying to connect, they get RSTs back.

> > +	If you want backwards compatibility with every possible application,
> > +	you should set it to 1. If you prefer to enhance security on your
> > +	systems at the risk of breaking very rare specific applications, you'd
> > +	better let it to 0.
> > +	Default: 0
> 
> This text leaves an impression that they exist.

In doubt, I consider that they might exist. It's just like martians :-)

Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

On Sun, 12 Jun 2005 20:14:25 +0200, Willy Tarreau said:
> On Sun, Jun 12, 2005 at 08:47:07PM +0300, Denis Vlasenko wrote:

> > Very nice. BTW, is there any real world applications which
> > ever used this?
> 
> Not that I'm aware of, but that does not mean they don't exist. Until
> yesterday, I even thought that it was never implemented. As most other
> systems don't implement it, the applications, if they exist, are Linux
> or BSD-dependant.

A more likely explanation is that there existed TOPS-20 or Multics code
that actually used that for something.  Remember that BSD and Linux both
came along long after RFC793 came out....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Sun, Jun 12, 2005 at 04:24:01PM +0200, Willy Tarreau wrote:
>
> 1) no firewall in front of A
>   - C spoofs A and sends a fake SYN to B
>   - B responds to A with a SYN-ACK
>   - A sends an RST to B, which clears the session
>   - A wants to connect and sends its SYN to B which accepts it.

Well the attacker simply has to keep sending the same SYN packet
over and over again until A runs out of SYN retries.

What I really don't like about your patch is the fact that it is
trying to impose a policy decision (that of forbidding all
simultaneous connection initiations) inside the TCP stack.

A much better place to do that is netfilter.  If you do it there
then not only will your protect all Linux machines from this attack,
but you'll also protect all the other BSD-derived TCP stacks.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Mon, Jun 13, 2005 at 02:48:10PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 04:24:01PM +0200, Willy Tarreau wrote:
> >
> > 1) no firewall in front of A
> >   - C spoofs A and sends a fake SYN to B
> >   - B responds to A with a SYN-ACK
> >   - A sends an RST to B, which clears the session
> >   - A wants to connect and sends its SYN to B which accepts it.
> 
> Well the attacker simply has to keep sending the same SYN packet
> over and over again until A runs out of SYN retries.
> 
> What I really don't like about your patch is the fact that it is
> trying to impose a policy decision (that of forbidding all
> simultaneous connection initiations) inside the TCP stack.

It's the same for ECN or SYN cookies.

> A much better place to do that is netfilter.  If you do it there
> then not only will your protect all Linux machines from this attack,
> but you'll also protect all the other BSD-derived TCP stacks.

Netfilter already blocks simultaneous connection. A SYN in return to
a SYN produces an INVALID state.

Cheers,
Willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau]

On Mon, Jun 13, 2005 at 03:24:04PM +1000, Herbert Xu wrote:
> On Mon, Jun 13, 2005 at 07:21:48AM +0200, Willy Tarreau wrote:
> > 
> > > A much better place to do that is netfilter.  If you do it there
> > > then not only will your protect all Linux machines from this attack,
> > > but you'll also protect all the other BSD-derived TCP stacks.
> > 
> > Netfilter already blocks simultaneous connection. A SYN in return to
> > a SYN produces an INVALID state.
> 
> Any reason why that isn't enough?

I don't think there are a lot of people who load ip_conntrack and insert
a single DROP rule on their servers just to workaround weaknesses in the
TCP stack. If they did, they would not be more confident into netfilter
either because it would be logical to expect the same reasoning (eg: let's
not fix XX here, TCP will catch it).

What's the problem with the sysctl ? If you prefer, I can change the patch
to keep the feature enabled by default so that only people aware of the
problem have to fix it by hand. But I found it better the other way : people
who need the feature enable it by hand.

Cheers,
willy

Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Herbert Xu]

On Mon, Jun 13, 2005 at 08:17:48AM +0200, Willy Tarreau wrote:
> 
> What's the problem with the sysctl ? If you prefer, I can change the patch
> to keep the feature enabled by default so that only people aware of the
> problem have to fix it by hand. But I found it better the other way : people
> who need the feature enable it by hand.

Well that's exactly my problem :)

I reckon it should be off by default because the threat posed by
this problem is IMHO small compared to some of the other standard
threats that are applicable to TCP.  Plus this is a well-documented
feature so we can't be sure that someone somewhere isn't depending
on it.

However, if it were off by default then there is very little value
in providing it at all since the same thing can be achived easily
through netfilter.

Anyway, let's leave it to Dave to make the decision.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt