[unisog] TCP reset issues

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Wed Apr 21 16:02:34 GMT 2004


On Tue, 20 Apr 2004 15:17:27 PDT, "Lucy E. Lynch" <llynch at darkwing.uoregon.edu>  said:
> Vulnerability Issues in TCP
> http://www.uniras.gov.uk/vuls/2004/236929/index.htm
> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
> http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml
> and a bit late to the party:
> http://www.us-cert.gov/cas/techalerts/TA04-111A.html

Actually, they're *all* late to the party.

RFC793, September 1981, section 3.4 clearly says:

  Reset Processing

  In all states except SYN-SENT, all reset (RST) segments are validated
  by checking their SEQ-fields.  A reset is valid if its sequence number
  is in the window.  In the SYN-SENT state (a RST received in response
  to an initial SYN), the RST is acceptable if the ACK field
  acknowledges the SYN.

So it isn't like this is a new issue - an RST has *never* had to actually
nail the seq number on the nose (a one in 2**32 chance unless you have help),
it's always been one in (2**32 / window size).

And it isn't like Michael Zalewski didn't point out that it's a lot smaller
than 1 in 2**32 for many machines:

http://lcamtuf.coredump.cx/newtcp/ (one year later)
http://razor.bindview.com/publish/papers/tcpseq.html  (original paper)

(Yes, that deals with ISNs rather than RST's - point is that you can't
trust RFC1948 to protect you on all platforms...)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/unisog/attachments/20040421/3b8a93bd/attachment-0003.bin


More information about the unisog mailing list