freebsd security - Apr 2004 - TCP RST attack

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.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.  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"
>

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

> 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.

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

> 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.

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"
sessions
GTSM works for multihop and this scenario is addressed in RFC3682.

-- 
- bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org

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

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)