BUG: Unusual TCP Connect() results.

BUG: Unusual TCP Connect() results.

[Alastair Poole]

I have tested various kernels including 2.6.11.10 2.6.11.11 and 
2.6.12-rc6 and am having unusual results regarding connect().  Earlier 
kernels do not return the same strange results.

I have tested numerous basic port scanners, including my own, and 
strangely ports which are NOT open are being reported as open.  I have 
checked these ports by various means -- to be certain they are NOT open 
-- and in various runlevels; the results are the same.

The number of ports listed changes in size and they appear to be 
random.  For example, on one scan ports 22, 3455, 4532 and 6236 will 
appear open; on another scan it might be 22, 3567, 3879, 3889, 6589 and 
7374. 

However, ports which ARE open do also appear as open alongside these 
"rogue" ports.  I have also tested this on another system with the same 
results.  It is also interesting to note that a basic TCP nmap scan does 
not return these unusual results.

Enclosed is example code that produces these results on the named 
kernels and systems.

sincerely

Alastair Poole

########################################################################

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <time.h>
#include <string.h>

int
main (int argc, char **argv)
{
  int sd, result, server_port;
  *struct* hostent *he;
  *struct* sockaddr_in servaddr;

  printf ("Test TCP/IP port scanner:\n");

  *if* (argc != 2)
    {
      printf ("Usage: %s host\n", argv[0]);
      exit (1);
    }

  *if* ((he = gethostbyname (argv[1])) == NULL)
    {
      perror ("gethostbyname()");
      exit (1);
    }

  printf ("Scanning %s\n", argv[1]);

  *for* (server_port = 0; server_port < 65536; server_port++)
    {
      *if* ((sd = socket (PF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1)
	{
	  perror ("socket()");
	  exit (1);
	}

      bzero (&servaddr, *sizeof* servaddr);
      servaddr.sin_family = AF_INET;
      servaddr.sin_port = htons (server_port);
      servaddr.sin_addr = *((*struct* in_addr *) he->h_addr);

      result = connect (sd, (*struct* sockaddr *) &servaddr, *sizeof* servaddr);

      *if* (result != -1)
	{
	  printf ("open port:  %d\n",server_port);
	}
      close (sd);
    }
  *return* result;
}


########################################################################

[OT] Re: BUG: Unusual TCP Connect() results.

[Kyle Moffett]

On Jun 9, 2005, at 16:51:39, Alastair Poole wrote:
> The number of ports listed changes in size and they appear to be
> random.  For example, on one scan ports

> 22, 3455, 4532 and 6236

SSH and 3 RPC-based services, I would guess.  This is not a kernel
bug, there are probably userspace applications which are opening
those ports, even something as simple as an FTP client in active
mode would do it.  Please run "netstat -lp" to determine which
processes have opened each port.

> It is also interesting to note that a basic TCP nmap scan does not
> return these unusual results.

nmap doesn't scan higher-numbered ports by default, because those
ports are generally allocated dynamically by the kernel when user
programs indicate they do not care what port they are bound on.

Cheers,
Kyle Moffett

Re: [OT] Re: BUG: Unusual TCP Connect() results.

[Alastair Poole]

Kyle Moffett wrote:

> SSH and 3 RPC-based services, I would guess.  This is not a kernel
> bug, there are probably userspace applications which are opening
> those ports, even something as simple as an FTP client in active
> mode would do it.  Please run "netstat -lp" to determine which 
> processes have opened each port.

 >> These ports are definately not opened, yet still connect() returns 0 
with new kernels for ports
 >> that it should not.  I should have been more specific with nmap; 
even when specifying port ranges
 >> nmap still does not return these odd results upon a basic tcp scan.  
Only basic scanner like the ones
 >> mentioned and included in the first post.  No other RPC services or 
TCP daemons are running
 >> these are definately rogue ports.  Running on x86 and kernels 
2.6.11.10, 2.6.11.11 and 2.6.12-rc6
 >> the unusual results still persist when using these basic port 
scanners upon localhost.  I have someone
 >> else who has confirmed to me the same results.  Can anyone here?

Re: BUG: Unusual TCP Connect() results.

[Michal Schmidt]

Alastair Poole wrote:
> I have tested various kernels including 2.6.11.10 2.6.11.11 and 
> 2.6.12-rc6 and am having unusual results regarding connect().  Earlier 
> kernels do not return the same strange results.

What is the last version that works as expected for you?

> I have tested numerous basic port scanners, including my own, and 
> strangely ports which are NOT open are being reported as open.  I have 
> checked these ports by various means -- to be certain they are NOT open 
> -- and in various runlevels; the results are the same.
> 
> The number of ports listed changes in size and they appear to be 
> random.  For example, on one scan ports 22, 3455, 4532 and 6236 will 
> appear open; on another scan it might be 22, 3567, 3879, 3889, 6589 and 
> 7374.
> However, ports which ARE open do also appear as open alongside these 
> "rogue" ports.  I have also tested this on another system with the same 
> results.  It is also interesting to note that a basic TCP nmap scan does 
> not return these unusual results.

Are you testing your scanner only on localhost? Maybe you are just lucky 
and connect your TCP socket to itself.

> Enclosed is example code that produces these results on the named 
> kernels and systems.
> [...]
> int
> main (int argc, char **argv)
> {
>  int sd, result, server_port;
>  *struct* hostent *he;
>  *struct* sockaddr_in servaddr;

What are these asterisks doing there? Next time when you copy&paste 
code, please make sure you don't mangle it.

Michal

Re: BUG: Unusual TCP Connect() results.

[Alastair Poole]

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

Michal Schmidt wrote:

>>> What is the last version that works as expected for you?
>>
Kernel 2.6.11, though I can't check others due to bandwidth 
restrictions.  2.6.11.10 through 2.6.12-rc6 all have the same issue.

>>> Are you testing your scanner only on localhost? Maybe you are just 
>>> lucky and connect your TCP socket to itself.
>>
This problem only occurs on localhost.  I don't think it is mere luck, 
these are too frequent and strange for this.

>>>
>>> What are these asterisks doing there? Next time when you copy&paste 
>>> code, please make sure you don't mangle it.
>>>
I apologise for this, included this time is an attatchment in the hope 
you are able to reproduce the strange results I and others have been 
able to.  Try testing multiple times, I find that 18 out of 20 runs 
produces the same type of results.

sincerely

Alastair Poole

[-- Attachment #2: scan.c --]
[-- Type: text/plain, Size: 1184 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <time.h>
#include <string.h>

int
main (int argc, char **argv)
{
 int sd, result, server_port;
 struct hostent *he;
 struct sockaddr_in servaddr;

 printf ("Test TCP/IP port scanner:\n");

 if (argc != 2)
   {
     printf ("Usage: %s host\n", argv[0]);
     exit (1);
   }

 if ((he = gethostbyname (argv[1])) == NULL)
   {
     perror ("gethostbyname()");
     exit (1);
   }

 printf ("Scanning %s\n", argv[1]);

 for (server_port = 0; server_port < 65536; server_port++)
   {
     if ((sd = socket (PF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1)
    {
      perror ("socket()");
      exit (1);
    }

     bzero (&servaddr, sizeof servaddr);
     servaddr.sin_family = AF_INET;
     servaddr.sin_port = htons (server_port);
     servaddr.sin_addr = *((struct in_addr *) he->h_addr);

     result = connect (sd, (struct sockaddr *) &servaddr, sizeof servaddr);

     if (result != -1)
    {
      printf ("open port:  %d\n",server_port);
    }
     close (sd);
   }
 return result;
}

Re: BUG: Unusual TCP Connect() results.

[Michal Schmidt]

Alastair Poole wrote:
> This problem only occurs on localhost.  I don't think it is mere luck, 
> these are too frequent and strange for this.

I tried the scanning program on localhost. I modified it to wait for the 
user to press Enter when it encounters an open port.
On my system I normally have listening TCP ports 25, 631 and 1024.
And yes, the scanning program sometimes finds other open ports.
This is netstat output when it happens:

michich@michichnb:~> LC_ALL=C netstat -ntp | grep scan
(Not all processes could be identified, non-owned process info
  will not be shown, you would have to be root to see it all.)
tcp  0  0  127.0.0.1:1774   127.0.0.1:1774     ESTABLISHED 17510/scan


The TCP socket connected to itself. I don't know if it's expected 
behaviour. It agree it is strange, because we didn't call listen() on 
the socket.

Michal

Re: BUG: Unusual TCP Connect() results.

[Willy TARREAU]

Hi,

just tried right here with a simpler prog which only connects to its
previously bound socket (prog at the end).

After the bind(), the socket still does not appear in netstat (normal),
but right after the connect() call, the socket appears as established.

It is documented in RFC793 (p30) as the simultaneous connection initation
from 2 clients, although this mode has never been implemented by any
mainline OS (to my knowledge) as it has no real use and poses security
problems (eases spoofing a lot). Moreover, stateful firewalls don't
support it at all for the same reasons. I think that this mode was
designed for point-to-point connections such as TCP over serial lines
or things like this.

Interestingly, the network capture on the 'lo' interface shows that the
protocol does not even match the case above, as it only shows the standard
SYN-SYN/ACK-ACK mechanism and not the dual, simultaneous one :

$ sudo tcpdump -Svvni lo tcp
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
00:04:03.688649 IP (tos 0x0, ttl  64, id 45241, offset 0, flags [DF], length: 60) 127.0.0.1.10000 > 127.0.0.1.10000: S [tcp sum ok] 1675767716:1675767716(0) win 32767 <mss 16396,sackOK,timestamp 2727709 0,nop,wscale 2>

00:04:03.688665 IP (tos 0x0, ttl  64, id 45243, offset 0, flags [DF], length: 60) 127.0.0.1.10000 > 127.0.0.1.10000: S [tcp sum ok] 1675767716:1675767716(0) ack 1675767717 win 32767 <mss 16396,sackOK,timestamp 2727709 2727709,nop,wscale 2>

00:04:03.688693 IP (tos 0x0, ttl  64, id 45245, offset 0, flags [DF], length: 64) 127.0.0.1.10000 > 127.0.0.1.10000: . [tcp sum ok] 1675767717:1675767717(0) ack 1675767717 win 8192 <nop,nop,timestamp 2727709 2727709,nop,nop,sack sack 1 {1675767716:1675767717} >

=> connection is ESTABLISHED

00:04:06.479729 IP (tos 0x0, ttl  64, id 45247, offset 0, flags [DF], length: 52) 127.0.0.1.10000 > 127.0.0.1.10000: F [tcp sum ok] 1675767717:1675767717(0) ack 1675767717 win 8192 <nop,nop,timestamp 2730501 2727709>

00:04:06.479781 IP (tos 0x0, ttl  64, id 45249, offset 0, flags [DF], length: 52) 127.0.0.1.10000 > 127.0.0.1.10000: . [tcp sum ok] 1675767718:1675767718(0) ack 1675767718 win 8192 <nop,nop,timestamp 2730501 2730501>

=> connection is TIME_WAIT.

It's even easier to test with netcat, which produces the same output :

   $ nc -s 127.0.0.1 -p 10000 127.0.0.1 10000

It works for any local address bound to any other interface :

   $ nc -s 10.0.0.1 -p 10000 10.0.0.1 10000

A test with hping2 between the bind() and connect() calls shows that the
connection is refused. I don't know if there's even a small window during
the connect() call during which external (spoofed) packets could validate
a connection. Even very fast local connections do not manage to steal a
connection in progress. All we can say is that it's very strange...

$ sudo hping2 -c 1 -k -a 10.0.0.1 -s 80 -I lo 10.0.0.1 -p 80 -S -M 12345678
//
$ sudo tcpdump -Svvni lo tcp
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
00:16:58.274961 IP (tos 0x0, ttl  64, id 63368, offset 0, flags [none], length:
40) 10.0.0.1.80 > 10.0.0.1.80: S [tcp sum ok] 12345678:12345678(0) win 512
00:16:58.275152 IP (tos 0x0, ttl  64, id 11, offset 0, flags [DF], length: 40) 10.0.0.1.80 > 10.0.0.1.80: R [tcp sum ok] 0:0(0) ack 12345679 win 0


Regards,
Willy

--

// Annex: simple connection program.

#include <stdio.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define MY_PORT 10000

int
main(int argc, char *argv[])
{
  int fd;
  int val;
  struct sockaddr_in addr;

  if ((fd = socket(PF_INET, SOCK_STREAM, 0)) < 0
      || setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &val, sizeof val) < 0) {
    perror("socket()");
    return 1;
  }

  addr.sin_family = AF_INET;
  addr.sin_port = htons(MY_PORT);
  addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
  memset(addr.sin_zero, 0, sizeof (addr.sin_zero));

  if (bind(fd, (struct sockaddr *)&addr, sizeof (addr)) < 0) {
    perror("bind()");
    return 1;
  }
  printf("bind ok. Press a key to continue.\n"); getchar();

  if (connect(fd, (struct sockaddr *)&addr, sizeof (addr)) < 0) {
    perror("connect()");
    return 1;
  }
  printf("connected! Press a key to continue.\n"); getchar();

  return 0;
} 

Re: BUG: Unusual TCP Connect() results.

[Willy Tarreau]

On Sat, Jun 11, 2005 at 12:26:45AM +0200, Willy TARREAU wrote:
 
> $ sudo hping2 -c 1 -k -a 10.0.0.1 -s 80 -I lo 10.0.0.1 -p 80 -S -M 12345678

Sorry, it was -s 10000 and -p 10000, I copy-pasted the wrong history line.

I also have verified that 2.4.30 behaves the same way with the netcat test.
So the difference between old and new versions should be that new versions
are able to allocate a source port for connect() eventhough this one should
be marked as used because of the bind(). This does not seem critical at all
anyway.

Regards,
Willy

Re: BUG: Unusual TCP Connect() results.

[David S. Miller]

From: Willy TARREAU <willy@w.ods.org>
Date: Sat, 11 Jun 2005 00:26:45 +0200

> It is documented in RFC793 (p30) as the simultaneous connection initation
> from 2 clients, although this mode has never been implemented by any
> mainline OS (to my knowledge) as it has no real use and poses security
> problems (eases spoofing a lot).

BSD (and thus BSD derivatives) and Linux have has it since
day one.  I guess it depends upon your definition of
"mainline OS". :-)

This is not a new feature.

Re: BUG: Unusual TCP Connect() results.

[Willy TARREAU]

Hi David,

On Fri, Jun 10, 2005 at 03:42:48PM -0700, David S. Miller wrote:
> From: Willy TARREAU <willy@w.ods.org>
> Date: Sat, 11 Jun 2005 00:26:45 +0200
> 
> > It is documented in RFC793 (p30) as the simultaneous connection initation
> > from 2 clients, although this mode has never been implemented by any
> > mainline OS (to my knowledge) as it has no real use and poses security
> > problems (eases spoofing a lot).
> 
> BSD (and thus BSD derivatives) and Linux have has it since
> day one.

Indeed, I've just managed to reproduce the full test with two different
addresses as it's described in p30. I never succeeded to do it before,
perhaps I did not try it the right way. To achieve this, I had to run two
programs doing while(connect()<0). I agree that on high latency networks,
it may make sense to support the feature (eg: mars-earth file transfers).

But on regular uses, I think it's more a problem than a feature, because
it allows any third party to prevent a normal connection establishment
by only knowing the source and destination, which are sometimes easily
guessable (eg: BGP between routers) :

  | A connects to B, C tries to block them by sending lots of SYN at
  | intervals smaller than the latency between A and B, eg 200/s for
  | a 10 ms latency.

  A                                       B (or C)
  ---------------+--------------------------------

                  <- SYN(SEQ=200)         (C sends blind SYN)
                  <- SYN(SEQ=200)         (C sends blind SYN)
  SYN(SEQ=100) -> ...
                  <- SYN(SEQ=200)         (C sends blind SYN)
  SYN(SEQ=101,ACK=201) ->                 (A acknowledges C's SYN)
                  <- SYN(SEQ=300,ACK=101) (B acknowledges A's SYN)
  RST(SEQ=102,ACK=301) ->                 (A rejects B's SYN/ACK)
                  <- RST(SEQ=201,ACK=102) (B rejects A's SYN/ACK)


Maybe it would be useful to have a sysctl option allowing us to disable
this behaviour when it can haev security implications ?

Also, I often test firewalls for such features and never found any one
which allows this. To be more precise, only a previous implementation of
the tcp-window-tracking in Netfilter allowed this but it opened a security
breach that we had to resolve with Jozsef, as it allowed the client to
establish a session by sending the SYN-SYN/ACK-ACK itself...

> I guess it depends upon your definition of
> "mainline OS". :-)

It does not depend on my definition, but on my knowledge, as I put the
condition in the initial mail that you quoted above :-)

Cheers,
Willy

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

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

[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 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: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.)

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

[Herbert Xu]

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

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

[Willy Tarreau]

On Mon, Jun 13, 2005 at 05:45:21PM +1000, Herbert Xu wrote:
> 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.

I understand your point of view.

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

At least, he has enough elements in his mailbox now :-)

Cheers,
Willy

Re: [PATCH] fix small DoS on connect()

[David S. Miller]

From: Willy Tarreau <willy@w.ods.org>
Date: Mon, 13 Jun 2005 10:10:26 +0200

> On Mon, Jun 13, 2005 at 05:45:21PM +1000, Herbert Xu wrote:
> > Anyway, let's leave it to Dave to make the decision.
> 
> At least, he has enough elements in his mailbox now :-)

I'm still thinking about this one, sit tight :)

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

[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: BUG: Unusual TCP Connect() results.

[Alastair Poole]

Should something be down to change this new behaviour to that of older 
kernels?  Or is this a feature that should stay?

Re: BUG: Unusual TCP Connect() results.

[Willy Tarreau]

On Sat, Jun 11, 2005 at 03:34:05PM +0000, Alastair Poole wrote:
> Should something be down to change this new behaviour to that of older 
> kernels?  Or is this a feature that should stay?
 
As David said, the simultaneous connect has always been there. The new
behaviour you observe might be the fact that the source port allocator
sometimes returns an address which is identical to the destination, and
that can seem somewhat strange. But I don't know if it's a new behaviour
or if it never showed up before because of race conditions.

Willy