ICMP vulnerabilities

[Theo de Raadt]

Much more information on the ICMP vulnerabilities that allow you to blindly
tear down TCP sessions.

http://kerneltrap.org/node/5382

Please note these are not man-in-the-middle attacks. You can do them
blind. Totally blind. You do not need to know any information.

There are three attacks outlined. They require very small numbers of
packets.

My favorite twist to this would be to slow BGP sessions down so they
(1) stay in TCP slow-start, (2) run with very small MTU. To do both
these things requires about 128,000 icmp packets, if I recall (perhaps
we can get real figures from gont).

a) The BGP session would effectively stall, since it cannot keep
up with the updates.
b) The BGP daemon would not know that the session has stalled.
The sub-net starts to become de-syncronized.

Once you are doing very small TCP packets with slow-start, you can
slow down on your icmp attack. You just need to re-tickle slow start
once in a while.

c) Eventually the BGP daemon would notice (based on timeouts) that
the session has stalled, and reset the connection.

When that happens, it will start a new BGP session. You know this
has happened because over BGP you can see the peer leaving.

d) the BGP daemon creates a new session.

You bombard it with ICMP again.

Repeat a few times -- and everyone will now consider that peer to be
flapping, and you have successfully taken an ISP off the net.


Please read the article. My take on this is that there are people
who don't want to fix this.

[J. Oquendo]

On Wed, 6 Jul 2005, Theo de Raadt wrote:

>
> Repeat a few times -- and everyone will now consider that peer to be
> flapping, and you have successfully taken an ISP off the net.
>
>
> Please read the article. My take on this is that there are people
> who don't want to fix this.
>

This isn't news news, I've been tinkering with something along these
lines since 1999:

http://antioffline.com/TID/
http://www.infiltrated.net/brat.c



=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ =+
J. Oquendo
GPG Key ID 0x97B43D89
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x97B43D89

To conquer the enemy without resorting to war is the most
desirable. The highest form of generalship is to conquer
the enemy by strategy." - Sun Tzu

[Dragos Ruiu]

On Thursday, 7 July 2005 J. Oquendo wrote:
> This isn't news news, I've been tinkering with something along
> these lines since 1999

Well you may have known about the problem, but you didn't fix it.
The news isn't the problem, it's the FIX. The fix which people haven't
applied to their OS distributions yet.

To reiterate:

On Wednesday, 6 July 2005 Theo de Raadt wrote:
> Please read the article.

People saw the presentation at CanSecWest and had the same reaction.
Oh that... it's an old problem. Well, it's not really if you look carefully.
It's an important problem and it needs to be fixed. Maybe the right
solution is to just release the kiddy-exploit-code and melt down a
few big ISPs for a couple of days so people stop parroting "It's an old
problem" and get down to fixing it.

It seems to me that this perception problem is caused by skirting the issue
and being oblique about how to explicitly use this attack to cause harm.
People are ignoring the fix because they can't immediately see how to
do the attack (it's somewhat subtle). Maybe what is needed is the
Internet-Wide-Scale-DoS-HOWTO and people will finally apply
the fix logic (which isn't that complicated as far as I can see).

But echoing "this is an old problem" isn't helping to propagate the fix.
So let's stop saying that.

Vendors, please fix your broken OSes.

cheers,
--dr

--
World Security Pros. Cutting Edge Training, Tools, and Techniques
Tokyo, Japan November 15/16 2005 http://pacsec.jp
pgpkey http://dragos.com/ kyxpgp

[Bob Beck]

> >
> > Please read the article. My take on this is that there are people
> > who don't want to fix this.
> >
>
> This isn't news news, I've been tinkering with something along these
> lines since 1999:
>

Well, your article is your ponderings of how tcp work, and brat.c
does nothing like an MTU attack, it simply floods someone's bgp port,
whoopee, buy your bot-net and go to town. - That's not what the
article is about. What fernando is talking about is not a flood which
requires a worm or something to grab enough bandwidth to attack
people, it's a blind attack which someone with idsn level connectivity
alone can probably send enough packets to make it work.

More importantly, the article is talking about FIXES for these
issues, rather than just wanking about it. It also seems to notice
that the corporate shills who have taken over the IETF are going out
of their way to ensure that things don't change in the standards, so
that their respective companies won't have to implement expensive
fixes that will cost them a lot of money to get to their customers.
This and combined with the aggressive tactics of companies like Cisco
who appeared to attempt to shut someone up who comes to the IETF with
an issue by threatening frivoulous legal action by claiming to patent
their work after the fact.

I find the whole story of how the IETF and the large companies
involved handling this very disturbing, although perhaps not surprising.

-Bob

[Joachim Schipper]

On Thu, Jul 07, 2005 at 05:02:40PM -0700, Dragos Ruiu wrote:
> On Thursday, 7 July 2005 J. Oquendo wrote:
> > This isn't news news, I've been tinkering with something along
> > these lines since 1999
>
> Well you may have known about the problem, but you didn't fix it.
> The news isn't the problem, it's the FIX. The fix which people haven't
> applied to their OS distributions yet.

On this note, does anyone know to what extent operating systems other
than OpenBSD are affected? The article lists FreeBSD and Linux as having
(partially) solved the issues; are the issues not named still
outstanding? Workaround? Patch?

Is Windows, once again, vulnerable? Cisco systems (seems to be the
case)?

Joachim