[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20051224060240.GA18547@openwall.com>
Date: Sat, 24 Dec 2005 09:02:40 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Local exploitation of a memory exhaustion vulnerability in Linux Kernel, versions 2.4 and 2.6
On Fri, Dec 23, 2005 at 12:02:51PM +0300, Maxim Timofeyev wrote:
> http://www.idefense.com/intelligence/vulnerabilities/display.php?id=362
So what?
I'll try to be creative and post a detailed response to your one-liner. ;-)
I could comment on the "advisory" and how iDEFENSE doesn't understand
stuff, but the real issue is that the existing resource limits are
insufficient to prevent local resource exhaustion attacks. Moreover, in
default installs of Owl, one can bypass the rlimits by having a program
invoked out of .forward (there is a public TODO item on making our
Postfix open PAM sessions to avoid that).
To deal with the many resource exhaustion scenarios, per-user limits
would need to be introduced. There's been some work done in that area -
implementation of so-called user beancounters (or UBC for short) in
1998-99 primarily by Alan Cox and Andrey Savochkin, but nothing went
into current mainstream kernels. Since then, Andrey has proceeded to
develop and maintain UBCs for SWsoft's Virtuozzo and now also for
OpenVZ, where the limits are applied per-VPS rather than per-user.
Some bits of the old 1998-99 discussion can be found here:
http://marc.theaimsgroup.com/?l=linux-security-audit&s=beancounters
OpenVZ homepage is here:
http://openvz.org
(Yes, OpenVZ "mostly works" with Owl - the status of this can be
discussed in a separate thread if anyone is interested.)
You may wonder whether we're planning to introduce per-user resource
limits, in whatever form, into Owl. The answer is - maybe, but this
definitely won't happen soon (well, unless someone highly skilled and
capable of working in a team would volunteer for this work and, more
importantly, would actually do it).
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
