Messages in this thread |  | | Date | Fri, 17 May 1996 15:44:30 -0400 | From | "Theodore Y. Ts'o" <> | Subject | [RFC Editor: RFC1948 on Sequence Number Attacks] |
| |
Steve Bellovin's proposal for defending against TCP connection hijacks has just been published as an RFC. As an aside, the RFC also discusses common TCP implementation bug. I assume that we're hopefully proof against it since we're not descended from the BSD stack, but we've added enough algorithms from BSD that's worth checking. Alan?
A Common TCP Bug ================
As mentioned earlier, attackers using sequence number guessing have to "gag" the trusted machine first. While a number of strategies are possible, most of the attacks detected thus far rely on an implementation bug.
When a packet is received, the first thing that must be done is a search for the TCB for that connection. If no TCB is found, the kernel searches for a "wild card" TCB used by servers to accept connections from all clients. Unfortunately, in many kernels this code is invoked for any incoming packets, not just for initial SYN packets. If the SYN-RCVD queue is full for the wildcard TCB, any new packets specifying just that host and port number will be discarded, even if they aren't SYN packets.
To gag a host, then, the attacker sends a few dozen SYN packets to the rlogin port from different port numbers on some non-existent machine. This fills up the SYN-RCVD queue, while the SYN+ACK packets go off to the bit bucket. The attack on the target machine then appears to come from the rlogin port on the trusted machine. The replies -- the SYN+ACKs from the target -- will be perceived as packets belonging to a full queue, and will be dropped silently. This could be avoided if the full queue code checked for the ACK bit, which cannot legally be on for legitimate open requests. If it is on, RST should be sent in reply.
I'll note that RFC1948's method of protecting against sequence number attacks requires either the use of a per-host secret (very hard to administer), OR the use of true random numbers as specified by RFC1750.
- Ted
------- Forwarded Message
To: IETF-Announce:;@IETF.CNRI.Reston.VA.US Subject: RFC1948 on Sequence Number Attacks Cc: rfc-ed@isi.edu Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 17 May 96 10:08:00 PDT Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US From: RFC Editor <rfc-ed@isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1948:
Title: Defending Against Sequence Number Attacks Author: S. Bellovin Date: May 1996 Mailbox: smb@research.att.com Pages: 6 Characters: 13,074 Updates/Obsoletes: none
URL: ftp://ds.internic.net/rfc/rfc1948.txt
IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks.
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example:
To: rfc-info@ISI.EDU Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.
Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information.
Joyce K. Reynolds USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.
--NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net"
Content-Type: text/plain Content-ID: <960517100606.RFC@ISI.EDU>
SEND /rfc/rfc1948.txt
--OtherAccess Content-Type: Message/External-body; name="rfc1948.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc"
Content-Type: text/plain Content-ID: <960517100606.RFC@ISI.EDU>
--OtherAccess-- --NextPart--
------- End Forwarded Message
|  |