http://www.uniras.gov.uk/vuls/2004/236929/index.htm ----Quote---- "The impact of this vulnerability varies by vendor and application, but in some deployment scenarios it is rated critical. Please see the vendor section below for further information. Alternatively contact your vendor for product specific information. If exploited, the vulnerability could allow an attacker to create a Denial of Service condition against existing TCP connections, resulting in premature session termination. The resulting session termination will affect the application layer, the nature and severity of the effects being dependent on the application layer protocol. The primary dependency is on the duration of the TCP connection, with a further dependency on knowledge of the network (IP) addresses of the end points of the TCP connection." ----Quote---- -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Mike Tancsa <mike@sentex.net> writes:> http://www.uniras.gov.uk/vuls/2004/236929/index.htmThe 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. The fact that you can attack a TCP connection which passes through a network you have access to sniff should not be a surprise to anyone; the remaining cases require spoofing of a type which egress filtering would prevent, if only people would bother implementing it. 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) 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. 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) DES -- Dag-Erling Sm?rgrav - des@des.no
Does anybody remember this: http://lcamtuf.coredump.cx/newtcp/ This seems fairly clear to me that guessing our tcp sequences is near omnipotent power. -Jon Mike Tancsa wrote:> At 02:26 PM 20/04/2004, Dag-Erling Sm?rgrav wrote: > >> Dragos Ruiu <dr@kyx.net> writes: >> > On April 20, 2004 10:44 am, Dag-Erling Sm?rgrav wrote: >> > > 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. >> > This is not true. The attack does not require sniffing. >> >> You need to know the source and destination IP and port. In most >> cases, this means sniffing. BGP is easier because the destination >> port is always 179 and the source and destination IPs are recorded in >> the whois database, but you still need to know the source port. > > > While true, you do need the source port, how long will it take to > programmatically go through the possible source ports in an attack ? > That only adds 2^16-1024 to blast through > > ---Mike > > > > > >> DES >> -- >> Dag-Erling Sm?rgrav - des@des.no > > > _______________________________________________ > 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" >
Mike Tancsa
2004-Apr-21 10:24 UTC
Other possible protection against RST/SYN attacks (was Re: TCP RST attack
At 12:54 PM 21/04/2004, Jacques A. Vidrine wrote:>On Wed, Apr 21, 2004 at 12:30:40PM -0400, Mike Tancsa wrote: > > > > One other technique that might help with respect to this attack is what > > Cisco implemented, commonly known as the "TTL hack" > > > > http://www.nanog.org/mtg-0302/hack.html > >More commonly known as GTSM and RFC 3682.Are there any "bad things" that can happen by doing this ? ---Mike
Borja Marcos
2004-Apr-21 13:06 UTC
Other possible protection against RST/SYN attacks (was Re: TCP RST attack
> Are there any "bad things" that can happen by doing this ?Well, not every BGP sessions are established between directly connected interfaces. This would not work with "multi-hop BGP" sessions :-) Borja.
Mike Tancsa
2004-Apr-21 13:13 UTC
Other possible protection against RST/SYN attacks (was Re: TCP RST attack
At 04:05 PM 21/04/2004, Borja Marcos wrote:>>Are there any "bad things" that can happen by doing this ? > > Well, not every BGP sessions are established between directly > connected interfaces. This would not work with "multi-hop BGP" sessions :-)Thanks, I realize that, especially with iBGP. However for directly connected eBGP peers, the question still stands. What side effects if any are there? Why is the default 64 and not some other number like 255... I am sure the answer is out there, I just need to find the question so I can cram it into google ;-) Perhaps this is a better topic for freebsd-net ? ---Mike
Borja Marcos
2004-Apr-21 13:21 UTC
Other possible protection against RST/SYN attacks (was Re: TCP RST attack
> Thanks, I realize that, especially with iBGP. However for directly > connected eBGP peers, the question still stands. > > What side effects if any are there? Why is the default 64 and not > some other number like 255... I am sure the answer is out there, I > just need to find the question so I can cram it into google ;-)I can only think that it is a reasonable default. With a ttl of 200, for example, a routing loop would waste a lot of bandwidth for each undeliverable packet. Borja.
Bill Fumerola
2004-Apr-21 15:20 UTC
Other possible protection against RST/SYN attacks (was Re: TCP RST attack
On Wed, Apr 21, 2004 at 10:05:49PM +0200, Borja Marcos wrote:> >Are there any "bad things" that can happen by doing this ? > > Well, not every BGP sessions are established between directly > connected interfaces. This would not work with "multi-hop BGP" sessionsGTSM works for multihop and this scenario is addressed in RFC3682. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org
Mike Tancsa
2004-Apr-21 17:31 UTC
Other possible protection against RST/SYN attacks (was Re: TCP RST attack
At 06:10 PM 21/04/2004, Gary Corcoran wrote:>>In any event, it still seems like a TTL of 255 is overkill for this >>application... > >Unless, of course, you want to only accept packets with TTL >of 255. This might be fine when both ends are setup to work >this way.Yes, but thats the whole point of it. By having the 2 BGP speakers *only* accept packets that have a TTL of 255, you are safe to bet it has not come across another router as no one has decremented the TTL value. ---Mike
Rumen Telbizov
2004-Apr-21 23:47 UTC
Other possible protection against RST/SYN attacks (was Re: TCP RST attack
Hi On Wed, Apr 21, 2004 at 08:32:32PM -0400, Mike Tancsa wrote:> At 06:10 PM 21/04/2004, Gary Corcoran wrote: > > >>In any event, it still seems like a TTL of 255 is overkill for this > >>application... > > > >Unless, of course, you want to only accept packets with TTL > >of 255. This might be fine when both ends are setup to work > >this way. > > Yes, but thats the whole point of it. By having the 2 BGP speakers *only* > accept packets that have a TTL of 255, you are safe to bet it has not come > across another router as no one has decremented the TTL value. >Just a comment on the topic: How about if _accidentally_ the routers are configured with the following option (or similar)? # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding # packets without touching the ttl). This can be useful to hide firewalls # from traceroute and similar tools. If the packet has been generated with ttl == 255 it would arrive with ttl == 255 to you after all, if all the routers are using this option! Just a thought! Rumen Telbizov
Heres my view on this hole thing and a solution to it: Take a step back from the problem, how is it caused? Spoofing of packets. Numerous vulnerabilities come from spoofed packets, and no doubt there will be more to come. If the ability to spoof packets on the internet was stopped, it would be much easier to fight such things, because they would not be possible. How to stop the spoofing? get ISPs to allow their customers to only send IP packets with the src address the same as their allocated ip(s) and drop the rest. If they all took the time to impliment this, they would not have to worry so much about patches later on because the probability of the packets being spoofed becomes so low. This could also be implimented on a higher level too (Asin the higher level ISPs doing similiar stuff)