[11059] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Shared memory DoS's

daemon@ATHENA.MIT.EDU (Dick St.Peters)
Sat Jul 17 06:08:09 1999

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id:  <14222.27194.20308.430298@saint.heaven.net>
Date:         Thu, 15 Jul 1999 19:09:46 -0400
Reply-To: "Dick St.Peters" <stpeters@NETHEAVEN.COM>
From: "Dick St.Peters" <stpeters@NETHEAVEN.COM>
X-To:         Mike Perry <mikepery@MIKEPERY.LINUXOS.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <19990715003612.A18130@mikepery.linuxos.org>

Mike Perry writes:

> So as it turns out that it is in fact possible to create a DoS condition by
> requesting a truckload of shared mem, then triggering pagefaults in the entire
> shared region.

Mapped memory segments have been susceptible to this since at least
the early days of VMS, which AFAIK was the first OS to implement
mapped memory (VMS used the term "mapped section").  I ran into this
by accident no later than 1982 while doing image processing on a VMS
system.  My processes run at the lowest possible priority (equivalent
to the highest possible niceness), would effectively shut down the
system until they completed.

VMS didn't have a lot of tools for analyzing what was happening, but a
few experiments quickly showed the culprit was page faulting.  Image
processing tends to step through memory sparsely.

Sorry - I no longer have an exploit :)

--
Dick St.Peters, stpeters@NetHeaven.com
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

home help back first fref pref prev next nref lref last post