[ISN] Steve Gibson invents broken SYNcookies

From: InfoSec News (isnat_private)
Date: Mon Feb 25 2002 - 23:12:18 PST

  • Next message: InfoSec News: "[ISN] Q&A with ICANN's security chairman, Stephen Crocker"

    By Thomas C Greene in Washington
    Posted: 25/02/2002 at 14:33 GMT
    He dares to call it "GENESIS" (Gibson's ENcryption-Enhanced Spoofing
    Immunity System). He dares to call it "Beautiful and Perfect." It's
    the product of "Three Key Innovations" for which he takes credit and
    which culminate in an "Encrypted Token," which is another way of
    saying a "SYNcookie", a quite useful thing developed by Dan Bernstein
    and Eric Schenk back in 1996.
    He dares to claim "immunity" from SYN floods. Only Steve Gibson's lame
    knockoff is dangerously broken.
    What it is
    A SYN flood is a DoS attack in which server resources, not bandwidth,
    are stressed. It fakes the initial handshake of a TCP connection with
    spoofed IPs which the target machine is unable to answer, so the
    target machine allocates system resources in anticipation of a
    connection which is never completed. Re-tries and time-outs add up to
    perhaps three minutes per bogus SYN. A server's capacity to respond to
    legitimate requests can be devoured in a matter of seconds with very
    small packets. Only four or five compromised client machines can
    cripple a server; in this way it's a fiendishly economical attack.
    The handshake is simple: a client initiates with a SYN (synchronize)
    packet; the server replies with a SYN/ACK (synchronize/acknowledge)
    packet; and the client finalizes with an ACK (acknowledge) packet. If
    these steps are followed, a TCP connection is established between the
    GENESIS attempts to negotiate the handshake without allocating system
    resources until the client's IP can be verified. This is a
    common-sense approach, essential to SYNcookies as well. But SYNcookies
    were worked out over time by people who, unlike Gibson, have a solid
    grasp of TCP/IP and the machines it connects. Even so, it took time
    and collaboration, and intellectual modesty, to get all the kinks
    ironed out.
    Unfortunately Gibson is so infatuated with the self-created myth of
    his own genius that he can't be bothered to consult Bernstein and
    Schenk, or anyone else for that matter, but goes it alone, inspired
    only by his overweening pride and essential incompetence. Of course
    his "Beautiful and Perfect" creation is going to be sadly defective.
    How could it be otherwise?
    One Reg reader who wishes to remain anonymous believes that GENESIS is
    more than a mere failure, but actually worse than no SYN protection at
    all. It was this person who originally brought the GENESIS project to
    our attention, and s/he's offered some very insightful observations.
    How it's done
    Put simply, authenticating a TCP connection request requires the
    server to encrypt some aspect(s) of the client's and the server's
    status so as to ensure that the final ACK comes from the same source
    as the original SYN (pun fully intended).
    Data such as the client's ISN (Initial Sequence Number), originating
    IP and port, MSS (Maximum Segment Size), and the server's IP and port,
    can be hashed to produce a server ISN which must be available for
    decoding in the final ACK packet. If the arithmetic fails, the ACK is
    rejected and no resources are devoted to the bogus connection. If it
    works out, a connection is made.
    Old cookies absolutely need to expire so they can't be reused; and old
    ISNs need to be identifiable so that they don't get mixed up with
    those belonging to a newer connection. Something unique ('secret')
    needs to be plugged into the hash so that cookies valid for one server
    can't be used on another, and so that valid ISNs can't be guessed or
    bruteforced easily.
    Anyone who reads Bernstein and Schenk's correspondence linked above
    will see that authenticating a SYN request is no trivial matter. There
    are a number of obstacles, but Gibson manages to overcome only one of
    them. Yes, he does manage to deal with the problem of disembodied
    sequence numbers, so that out-of-date numbers aren't carried over to
    complicate packet reconstruction on a new connection.
    But Gibson is silent on the rest of the issues Bernstein and Schenk
    have labored to solve.
    First, he offers no means to cause a cookie (or "Encrypted Token," as
    he prefers to call it), to expire. A valid cookie can be used to
    establish a connection. A lot of valid cookies can be used to
    establish a lot of connections. Perhaps Gibson is unfamiliar with the
    term 'packet sniffer.' Too bad. We'll just sit back and watch the
    kiddies gather up zillions of his broken SYNcookies to use against the
    fools who trust him.
    Second, he ignores MSS. It's hard to achieve decent performance
    without knowing it.
    Third, he doesn't use a secret, which means that valid ISNs can be
    bruteforced and valid ACKs generated -- and abused.
    Fourth, he uses RC5, which is slower than MD5 used in SYNcookies --
    another performance hit (just in case his gross security sloppiness
    didn't already frighten you away).
    Pants on fire
    Gibson dares to pretend that he'd never heard of SYNcookies when he
    set off in quest of beauty and perfection. "Immediately after I posted
    the second part of this work to the Web, several participants in the
    news groups at grc.com reported that similar work had been done
    before. I was unaware of previous work in this area, and consequently
    developed my solution independently and without the benefit of any
    previous work," Steve claims.
    I don't believe a word of it. I think he deliberately set out to
    knock-off SYNcookies and simply failed because the work was too
    difficult. He's not an übergeek; he just plays one on his Web site.
    I did a Google search and turned up more than 7,000 Web pages with the
    terms 'SYNcookies' or 'SYN cookies'. This guy is hacking TCP, yet he
    never once encountered a single mention of it?
    Impossible. No human being could have his head that far up his own ass
    -- not even Steve Gibson. 
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.

    This archive was generated by hypermail 2b30 : Tue Feb 26 2002 - 02:38:01 PST