SYN cookies security bugfix?

SYN cookies security bugfix?

[B. James Phillippe]

Hello,

I received a forwarded message from SuSE regarding a security vulnerability
with respect to randomization of the ISN for SYN cookies - or something to
that effect.  I have not been able to find the patch which addresses this
problem; if anyone can point me towards it, I would be appreciative.

thanks,
-bp
--
# bryanxms at ecst dot csuchico dot edu       Support the American Red Cross
# Software Engineer                               http://www.redcross.org

Re: SYN cookies security bugfix?

[Gianni Tedesco]

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

On Thu, 2001-11-08 at 05:20, B. James Phillippe wrote:
> Hello,
> 
> I received a forwarded message from SuSE regarding a security vulnerability
> with respect to randomization of the ISN for SYN cookies - or something to
> that effect.  I have not been able to find the patch which addresses this
> problem; if anyone can point me towards it, I would be appreciative.

Hi,

Think this is the patch you want - (backported it from 2.4.14 to 2.4.9).

-- 
// Gianni Tedesco <gianni@ecsc.co.uk>
"Every great advance in natural knowledge has involved
the absolute rejection of authority." -- Thomas H. Huxley

[-- Attachment #2: syncookie-fix.diff --]
[-- Type: text/x-patch, Size: 2571 bytes --]

diff -urN linux.orig/include/net/sock.h linux/include/net/sock.h
--- linux.orig/include/net/sock.h	Wed Aug 15 22:21:32 2001
+++ linux/include/net/sock.h	Wed Nov  7 14:24:36 2001
@@ -416,6 +416,8 @@
 	unsigned int		keepalive_time;	  /* time before keep alive takes place */
 	unsigned int		keepalive_intvl;  /* time interval between keep alive probes */
 	int			linger2;
+
+	unsigned long		last_synq_overflow;
 };
 
  	
diff -urN linux.orig/net/ipv4/syncookies.c linux/net/ipv4/syncookies.c
--- linux.orig/net/ipv4/syncookies.c	Wed May 16 18:31:27 2001
+++ linux/net/ipv4/syncookies.c	Wed Nov  7 14:23:54 2001
@@ -9,7 +9,7 @@
  *      as published by the Free Software Foundation; either version
  *      2 of the License, or (at your option) any later version.
  * 
- *  $Id: syncookies.c,v 1.14 2001/05/05 01:01:55 davem Exp $
+ *  $Id: syncookies.c,v 1.17 2001/10/26 14:55:41 davem Exp $
  *
  *  Missing: IPv6 support. 
  */
@@ -23,8 +23,6 @@
 
 extern int sysctl_tcp_syncookies;
 
-static unsigned long tcp_lastsynq_overflow;
-
 /* 
  * This table has to be sorted and terminated with (__u16)-1.
  * XXX generate a better table.
@@ -53,7 +51,9 @@
 	int mssind;
 	const __u16 mss = *mssp;
 
-	tcp_lastsynq_overflow = jiffies;
+	
+	sk->tp_pinfo.af_tcp.last_synq_overflow = jiffies;
+
 	/* XXX sort msstab[] by probability?  Binary search? */
 	for (mssind = 0; mss > msstab[mssind + 1]; mssind++)
 		;
@@ -78,14 +78,11 @@
  * Check if a ack sequence number is a valid syncookie. 
  * Return the decoded mss if it is, or 0 if not.
  */
-static inline int cookie_check(struct sk_buff *skb, __u32 cookie) 
+static inline int cookie_check(struct sk_buff *skb, __u32 cookie)
 {
 	__u32 seq; 
 	__u32 mssind;
 
-  	if ((jiffies - tcp_lastsynq_overflow) > TCP_TIMEOUT_INIT)
-		return 0; 
-
 	seq = ntohl(skb->h.th->seq)-1; 
 	mssind = check_tcp_syn_cookie(cookie,
 				      skb->nh.iph->saddr, skb->nh.iph->daddr,
@@ -126,8 +123,8 @@
 	if (!sysctl_tcp_syncookies || !skb->h.th->ack)
 		goto out;
 
-	mss = cookie_check(skb, cookie);
-	if (!mss) {
+  	if (time_after(jiffies, sk->tp_pinfo.af_tcp.last_synq_overflow + TCP_TIMEOUT_INIT) ||
+	    (mss = cookie_check(skb, cookie)) == 0) {
 	 	NET_INC_STATS_BH(SyncookiesFailed);
 		goto out;
 	}
@@ -178,7 +175,7 @@
 			    opt && 
 			    opt->srr ? opt->faddr : req->af.v4_req.rmt_addr,
 			    req->af.v4_req.loc_addr,
-			    sk->protinfo.af_inet.tos | RTO_CONN,
+			    RT_CONN_FLAGS(sk),
 			    0)) { 
 		tcp_openreq_free(req);
 		goto out; 

Re: SYN cookies security bugfix?

[Alan Cox]

> I received a forwarded message from SuSE regarding a security vulnerability
> with respect to randomization of the ISN for SYN cookies - or something to
> that effect.  I have not been able to find the patch which addresses this
> problem; if anyone can point me towards it, I would be appreciative.

Its fixed in 2.2.20, you can grab the 2.2 patch from there

test SYN cookies (was Re: SYN cookies security bugfix?)

[Ed L Cashin]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > I received a forwarded message from SuSE regarding a security vulnerability
> > with respect to randomization of the ISN for SYN cookies - or something to
> > that effect.  I have not been able to find the patch which addresses this
> > problem; if anyone can point me towards it, I would be appreciative.
> 
> Its fixed in 2.2.20, you can grab the 2.2 patch from there

What is a good way to test SYN cookies?  I can induce a three-second
delay (on victim host V) before new TCP connections are accepted by
sending a burst of 2000 SYN packets (from attacker A), where V is
running a 2.2.14 or 2.2.17 kernel.  During the three seconds ICMP echo
requests from A to V are being answered.

Turning on SYN cookies after /proc is mounted does not affect the
three-second pause, though, so I figure that either the pause is not
on account of a full half-open connection queue or SYN cookies are not
working.

-- 
--Ed Cashin                   PGP public key:
  ecashin@terry.uga.edu       http://www.terry.uga.edu/~ecashin/pgp/

Re: test SYN cookies (was Re: SYN cookies security bugfix?)

[Ed L Cashin]

Ed L Cashin <ecashin@terry.uga.edu> writes:

...
> What is a good way to test SYN cookies?  I can induce a three-second
> delay (on victim host V) before new TCP connections are accepted by
> sending a burst of 2000 SYN packets (from attacker A), where V is
> running a 2.2.14 or 2.2.17 kernel.  During the three seconds ICMP echo
> requests from A to V are being answered.
> 
> Turning on SYN cookies after /proc is mounted does not affect the
> three-second pause, though, so I figure that either the pause is not
> on account of a full half-open connection queue or SYN cookies are not
> working.

OK, I have found out that when I use three hosts to try to test SYN
cookies there is no pause, so the pause was a red herring.  However,
tests still seem to indicate that the SYN cookies feature doesn't do
anything. 

Host A sends a SYN flood to host B, now sporting a new 2.2.20 kernel
(with SYN cookie support, of course).  Host C makes repeated TCP
connections and ICMP echo requests to host B in order to monitor host
B.

However, even after setting tcp_max_syn_backlog to 1 on host B, I do
not observe any difference in connection times (from B to C) during a
SYN flood (from A to B) whether tcp_syncookies are on or off on host B
(1 or 0).  I am restarting the server on B each time I make an
adjustment in /proc.

Is there anyone who has any evidence that SYN cookies do anything in
kernel 2.2.x?  If so, how did you get that evidence, because I would
like to reproduce it.

-- 
--Ed Cashin                   PGP public key:
  ecashin@terry.uga.edu       http://www.terry.uga.edu/~ecashin/pgp/

Re: test SYN cookies (was Re: SYN cookies security bugfix?)

[Alan Cox]

> Is there anyone who has any evidence that SYN cookies do anything in
> kernel 2.2.x?  If so, how did you get that evidence, because I would
> like to reproduce it.

They work fine for me in 2.2.19/2.2.20. Make sure you compile them in and 
turn them on. Also remember syn cookies ensure connection completions for
real connections, they dont deal with servers that simply cant keep up with
real work

Re: test SYN cookies (was Re: SYN cookies security bugfix?)

[Ed L Cashin]

Thank you much for the reply.

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > Is there anyone who has any evidence that SYN cookies do anything in
> > kernel 2.2.x?  If so, how did you get that evidence, because I would
> > like to reproduce it.
> 
> They work fine for me in 2.2.19/2.2.20. 

That was reassuring enough that I persisted and found that the problem
was this: my home-spun SYN-flooder wasn't changing the TCP sequence
number, and so the "victim" was discarding the packets.  

The three-second pause I observed previously was a red herring that
went away when I started using separate hosts for flooding and
connection-testing. 

Now I see a night-and-day difference between with and without SYN
cookies (although when tcp_max_syn_backlog is set to more than a five
it takes a long time to fill the queue).

Thanks again.

-- 
--Ed Cashin                   PGP public key:
  ecashin@terry.uga.edu       http://www.terry.uga.edu/~ecashin/pgp/