full-disclosure - 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: <6.2.0.14.0.20050720194708.038d8140@pop.frh.utn.edu.ar>
Date: Wed Jul 20 23:59:33 2005
From: fernando at frh.utn.edu.ar (Fernando Gont)
Subject: Re: ICMP-based blind performance-degrading attack

At 07:42 p.m. 20/07/2005, Darren Reed wrote:

>Go look in the bugtraq archives for 8 July 2001 and you might find an
>email like the one below.  THere was a thread on this topic then.
>
>It would be nice if you included a referral or something in your IETF
>draft to my original work on this, 4 years ago.  Unless you want to
>try and proclaim that discussion on bugtraq isn't public knowledge
>and your discoveries are somehow "new".

Did you read the "Introduction" of the draft?
Where are the claims you mention?

The new stuff is the counter-measures, not the attacks.



>This is just one pointer to a start of the thread then...
>http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00124.html

This attack was even mentioned in RFC 1191.

So nobody could "discover" it, because the authors of RFC 1191 themselves 
stated that this attack could be performed.

Now, provide a pointer to a discussion of the counter-measures proposed in 
my internet-draft.


[Quoting your "old e-mail"]

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



>About the only bonus to this is that there does not appear to be an
>easy way to affect the MSS sent in the initial SYN packet.
>
>Oh, so how's this a potential denial of service attack?  Generally,
>network efficiency comes through sending lots of large packets...but
>don't tell ATM folks that, of course :-)  Does it work?  *shrug* It
>is not easy to test...the only testing I could do (with NetBSD) was
>to use the TCP_MAXSEG setsockopt BUT this only affects the sending
>MSS (now what use is that ? :-), but in testing, changing it from
>the default 1460 to 1 caused number of packets to go from 9 to 2260
>to write 1436 bytes of data to discard.  To send 100 * 1436 from
>the NetBSD box to Solaris8 took 60 seconds (MSS of 1) vs ~1 with
>an MSS of 1460.

This doesn't sound like an ICMP-based attack, BTW.



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

--
Fernando Gont
e-mail: fernando@...t.com.ar || fgont@....org