[lkml]   [1996]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    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 <>


    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
    Pages: 6
    Characters: 13,074
    Updates/Obsoletes: none


    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.

    Content-Type: Multipart/Alternative; Boundary="OtherAccess"

    Content-Type: Message/External-body;

    Content-Type: text/plain
    Content-ID: <960517100606.RFC@ISI.EDU>

    SEND /rfc/rfc1948.txt

    Content-Type: Message/External-body;

    Content-Type: text/plain
    Content-ID: <960517100606.RFC@ISI.EDU>


    ------- End Forwarded Message

     \ /
      Last update: 2005-03-22 13:37    [W:0.024 / U:3.556 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site