Re: TCP RST attack

From: Jacques A. Vidrine (nectar_at_FreeBSD.org)
Date: 04/21/04

  • Next message: Jacques A. Vidrine: "Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)"
    Date: Wed, 21 Apr 2004 06:47:20 -0500
    To: Dag-Erling Smørgrav <des@des.no>
    
    

    On Tue, Apr 20, 2004 at 07:44:37PM +0200, Dag-Erling Smørgrav wrote:
    > Mike Tancsa <mike@sentex.net> writes:
    > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm
    >
    > The advisory grossly exaggerates the impact and severity of this
    > fea^H^H^Hbug. The attack is only practical if you already know the
    > details of the TCP connection you are trying to attack, or are in a
    > position to sniff it.

    Well, the whole point is that *although in the past it was widely
    believed otherwise*, this attack is practical today in some real world
    situations. It many cases the only unknown is the source port number,
    and even that can be predictable.

    [...]
    > I don't believe BGP sessions are as exposed as the advisory claims
    > they are, either. The possibility of insertion attacks (which are
    > quite hard) was predicted six years ago, when RFC 2385 (Protection of
    > BGP Sessions via the TCP MD5 Signature Option) was written. RST
    > attacks may cause route flapping, but that can be avoided with a short
    > hysteresis (though this may be impractical for backbone routers)

    If the DoS attack causes route flapping, then the attack is a success.

    > Insertion attacks against SSL connections are practically impossible,
    > so the only risk there is an RST attack, which most browsers should
    > handle gracefully.
    >
    > DNS connections (even zone transfers) are so short-lived that you
    > would have to be very, very lucky to pull off an insertion or RST
    > attack against.

    Yes, these seem to be stretches.

    > The most likely attack scenario to come out of this is probably gamers
    > and IRC weenies kicking eachother off servers (the server's IP address
    > and port number are known, the servers often reveal client IP
    > addresses to other clients, and the client often uses a fixed source
    > port, or one from a relatively small range)

    Every time someone is kicked off an IRC server (or otherwise restrained
    from online chat), global productivity rises :-)

    Cheers,

    -- 
    Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
    

  • Next message: Jacques A. Vidrine: "Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd)"

    Relevant Pages

    • Re: TCP RST attack
      ... The advisory grossly exaggerates the impact and severity of this ... The attack is only practical if you already know the ... The fact that you can attack a TCP connection ... the servers often reveal client IP ...
      (FreeBSD-Security)
    • Re: TCP RST attack
      ... > The advisory grossly exaggerates the impact and severity of this ... The attack is only practical if you already know the ... The fact that you can attack a TCP connection ... increase the amount of work an attacker has to do to create a valid RST ...
      (FreeBSD-Security)
    • Re: Port 80 SYN flood-like behavior
      ... > were on the receiving end of such an attack a little over one month ago. ... > across a LARGE number of TCP servers. ... > SYN/ACK packets ... ... Traffic reflection off routers ...
      (Incidents)
    • [NT] Multiple Vulnerabilities in Mirabilis ICQ Client
      ... The ICQ client offers other client services, ... This vulnerability can be successfully exploited by an attacker ... ICQ Features on Demand spoofing attack: ...
      (Securiteam)
    • [REVS] DNS Amplification Attacks
      ... DNS Amplification Attacks ... One of the networks under attack indicated some ... exploited name servers. ...
      (Securiteam)