Subject: Re: CERT VU#637934 (PAWS)
To: None <tech-security@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-security
Date: 06/27/2005 22:53:46
In article <20050627051005.GA13496@panix.com>,
Ed Ravin  <eravin@panix.com> wrote:
>What's the status of this vulnerability with NetBSD?  CERT lists NetBSD as
>"unknown", notified March 9, 2005.  Both FreeBSD and OpenBSD are listed as
>"vulnerable".
>
>-------------------
>  http://www.kb.cert.org/vuls/id/637934
>
>  TCP does not adequately validate segments before updating timestamp value
>
>  Overview
>
>  Certain TCP implementations may allow a remote attacker to arbitrarily
>  modify host timestamp values, leading to a denial-of-service condition.
>
>  I. Description
>
>  The Transmission Control Protocol (TCP) is defined in RFC 793 as a means to
>  provides reliable host-to-host transmission between hosts in a
>  packet-switched computer networks. RFC 1323 introduced techniques to
>  increase the performance of TCP. Two such techniques are TCP timestamps and
>  Protection Against Wrapped Sequence Numbers (PAWS).

I should stop playing security officer... The problem was fixed by
mycroft on 26-Jan-05 in revision 1.213 of tcp_input.c. This fixed
has been pulled up in the 2.0 branch. Versions of tcp_input.c prior
to that revision would either panic for kernels compiled with
-DDIAGNOSTIC, or exhibit unpredictable tcp behavior for those
connections.

To bring the code more inline with FreeBSD and OpenBSD we should commit
the following:

christos

Index: tcp_input.c
===================================================================
RCS file: /cvsroot/src/sys/netinet/tcp_input.c,v
retrieving revision 1.229
diff -u -u -r1.229 tcp_input.c
--- tcp_input.c	6 Jun 2005 12:10:09 -0000	1.229
+++ tcp_input.c	27 Jun 2005 19:52:04 -0000
@@ -1571,10 +1571,25 @@
 		/*
 		 * If last ACK falls within this segment's sequence numbers,
 		 *  record the timestamp.
+		 * NOTE: 
+		 * 1) That the test incorporates suggestions from the latest
+		 *    proposal of the tcplw@cray.com list (Braden 1993/04/26).
+		 * 2) That updating only on newer timestamps interferes with
+		 *    our earlier PAWS tests, so this check should be solely
+		 *    predicated on the sequence space of this segment.
+		 * 3) That we modify the segment boundary check to be 
+		 *        Last.ACK.Sent <= SEG.SEQ + SEG.Len  
+		 *    instead of RFC1323's
+		 *        Last.ACK.Sent < SEG.SEQ + SEG.Len,
+		 *    This modified check allows us to overcome RFC1323's
+		 *    limitations as described in Stevens TCP/IP Illustrated
+		 *    Vol. 2 p.869. In such cases, we can still calculate the
+		 *    RTT correctly when RCV.NXT == Last.ACK.Sent.
 		 */
 		if (opti.ts_present &&
 		    SEQ_LEQ(th->th_seq, tp->last_ack_sent) &&
-		    SEQ_LT(tp->last_ack_sent, th->th_seq + tlen)) {
+		    SEQ_LEQ(tp->last_ack_sent, th->th_seq + tlen +
+		    ((tiflags & (TH_SYN|TH_FIN)) != 0))) {
 			tp->ts_recent_age = tcp_now;
 			tp->ts_recent = opti.ts_val;
 		}