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] [thread-next>] [day] [month] [year] [list]
Date: Sat, 10 Apr 2004 03:56:51 +1000 (Australia/ACT)
From: Darren Reed <avalon@...igula.anu.edu.au>
To: gandalf@...ital.net
Cc: bugtraq@...urityfocus.com
Subject: Re: IPv4 fragmentation --> The Rose Attack


In some mail from gandalf@...ital.net, sie said:
> 
> Greetings and Salutations:
> 
> On 4/8/04 1:26 PM, "Darren Reed" <avalon@...igula.anu.edu.au> wrote:
> > In some mail from Ventsislav Genchev, sie said:
> >> 
> >> I've tested the attack on 4 machines..
> >> The first two were running windows 98 SE with all patches and service
> >> packs... the CPU stuck the 100% as soon as the attack started..
> >> 
> > Is there any real point in testing Windows 9*, still ?
> > Does anyone care, including Microsoft, enough to want it fixed rather
> > than get people to upgrade to something that is better when it comes
> > to security, overall ?
> 
> From my experience in the real world, specifically with Windows 98 (and I
> suspect ME) I would say that yes we should care.  You would probably be
> frightened at the number of people still running Windows 9* and ME.

Let me put this in a different light...

Anyone or any corporation that cares about security, reliability of
their sytems, etc, is not going to be using Windows ME/9*, today.

In this particular case, whether someone is running Windows ME/9* is
irrelevant to me - it's a local attack against them that isn't likely
to affect me.

Further, most likely all the people who are still using Windows9*/ME
are not reading this, are not likely to ever hear about whether their
PC is vulnerable or understand it if they read about it in the paper.
Hence automatic updates in 2k/XP/...

> With a OS like Linux most people are *PROBABLY* on a newest version, but I
> bet you have companies who had a consultant parachute in, set up the Linux
> box and then leave.  Nobody touches the box because they are afraid to.

This is different to PC installations how ?

Anyone who assumes that people who use/run Linux automatically run the
latest version of anything has their head in the sand.  It just doesn't
happen like that for any number of reasons.  Just because you or anyone
else in the "open source community" can take the time and make the
effort to keep your software "current" does not necessarily mean that
even a majority do.  People have better things to do than reinstall
their desktops, loose all their settings each time, etc, every month
or 6 or 12 months.

Also, there's the problem of Linux in _devices_ where it may not be
possible to upgrade and quite possibly there, invisibly, to the owners
of the hardware.  The same is true for examining the BSDs.

> MoDem speeds:
> 1) Microsoft 2000 - 200 packets in less than 2 minutes completely shuts off
> legitimate fragmented packets
> 2) PIX - 200 packets in less than 5 to 20 seconds completely shuts off
> fragmentation

Recovery time or isn't there one ?

There is probably a similar "denial" attack against all firewalls
that keep track, in some manner, of fragments, where this is done
without requiring any active session.  Using "scrub" in pf comes
to mind as a "recent" innovation that is likely to be vulnerable
in a similar way to the aforementioned systems because "scrub"
rules that track fragments or do the defragmenting are independant
of the policy rule base (or at least that's how I remember it working.)
To extend it one step further to impact firewalls that require an
existing relationship before doing anything special for fragments,
a good suspect for an attack vehicle might be ICMP echo request
packets.

Unless it crashes the whole system, I don't think it's particularly
interesting as most people try and avoid dealing with frgaments,
these days, using PMTU discovery.

In contrast to other algorithms that try and prevent synflooding
(jamming the listen queue with SYN packets), there's no easy way
out here because the target of the attack is not expected to send
any packets back at the "source".  All you can seemingly do is play
around with limits and timeouts and things like that to at best
focus the problem.

Darren


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ