bugtraq - Re: ICMP-based blind performance-degrading attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <200507210535.j6L5Z4JL022733@caligula.anu.edu.au>
Date: Thu, 21 Jul 2005 15:35:04 +1000 (Australia/ACT)
From: Darren Reed <avalon@...igula.anu.edu.au>
To: fernando@....utn.edu.ar (Fernando Gont)
Cc: bugtraq@...urityfocus.com
Subject: Re: ICMP-based blind performance-degrading attack

In some mail from Fernando Gont, sie said:
> 
> The new stuff is the counter-measures, not the attacks.

Call me a cynic, but if you were focused on the counter-measure
side of things, you'd be providing patches, not exploits.

> >What's most surprising is that there does not appear to be a documented
> >minimum, just as there is no "minimum MTU" size for IP.  If there is,
> >please correct me.
> 
> Yes, there is: 68 bytes for IPv4, 1280 for IPv6.

The wording for this in RFC 791 is not nearly as concrete as that for
IPv6 in 2460.  Put it down to interpretation of English if you want
to disagree with me.

> >So, what are defences ?  Quite clearly the host operating system
> >needs to set a much more sane minimum MSS than 1.  Given there is
> >no minimum MTU for IP - well, maybe "68" - it's hard to derive
> >what it should be.  Anything below 40 should just be banned (that's
> >the point at which you're transmitting 50% data, 50% headers).
> >Most of the defaults, above, are chosen because it fits in well
> >with their internal network buffering (some use a default MSS of
> >512 rather than 536 for similar reasons).  But above that, what
> >do you choose? 80 for a 25/75 or something higher still?  Whatever
> >the choice and however it is calculated, it is not enough to just
> >enforce it when the MSS option is received.  It also needs to be
> >enforced when the MTU parameter is checked in ICMP "need frag"
> >packets.
> 
> So I must assume this e-mail discusses a blind ICMP-based attacks?

The email discusses the problems of small TCP packets due to the
segment size being set low.  Did I consider ICMP attacks at the time?
Yes.  Maybe I should have written an ICMP draft or made a white
paper about it, then.

Maybe if you had of focused on the fixes rather than trying to sell
a scary story I'd care differently.  As I said in another email, I've
been around long enough to have seen the rise and fall of one type
of ICMP attack (along with the associated doom & gloom) after another
so predictions of "the internet will collapse" fail to have any
weight in my eyes.

What do i expect will happen if someone running BGP sessions on a
vulnerable host will do if it does become a problem?  Block or
otherwise ignore that type of ICMP packet.  Will they care about
PMTU discovery?  Probably not, it's not like important BGP
sessions are going to be run over "funny MTU" links where these
messages are needed or are ever likely to be generated.

Don't get me wrong, I think the counter measures are good and
interesting, but there's absolutely nothing new about the blind
ICMP attack side of things (in case you hadn't got that message
already.)

Darren