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