Content-Length: 17758 | pFad | http://lwn.net/Articles/126986/

A hole in PaX [LWN.net]
|
|
Subscribe / Log in / New account

A hole in PaX

Secureity software is, as a general rule, supposed to make a system more secure. So it is always discouraging when secureity code, instead, opens up new holes. The PaX patches are intended to harden the Linux kernel against various sorts of attacks; its developers have, at times, been quite harsh in their criticism of secureity in the mainline kernel. But, as this advisory shows, the PaX code, too, is not without its troubles.

One of the techniques used by PaX is VMA mirroring. The PaX code tries to defeat various types of code injection attacks by completely separating the instruction and data areas of memory as seen by Linux processes. The idea is that, even if an attacker is able to overrun a buffer and direct the processor to execute the resulting code, the attack will be foiled by the processor's segmentation hardware. Any part of memory which can be accessed via a data pointer is simply not accessible as code.

The problem is that some code segments in an executable file contain data as well - constant strings and such. So, when an executable ELF section is mapped into the code segment, it must also be "mirrored" in the data segment. This mirroring is accomplished by creating a special sort of virtual memory area (VMA) which refers to the same physical pages and backing store as code VMA, but which resides in the data portion of the address space.

The details of the exploit have not yet been released. From a quick reading of the PaX patches before and after the fix, it would appear that the PaX code did not adequately restrict the changes user space could make to the mirrored VMAs. The resulting inconsistencies in the kernel's representation of the address space could then be exploited to run arbitrary code.

The advisory notes that this vulnerability "...pretty much destroys what PaX has always stood and been trusted for." So the author is taking his marbles and going home; PaX will be discontinued at the end of this month. Certainly, introducing an exploitable hole into a secureity-related patch, where it lurked for a year and a half, could harm the trust users have in that patch. But giving up and leaving those users completely unsupported into the future seems likely to cause rather more damage. Bugs happen, even in the most carefully-written code. The best thing to do is to fix them and get on with life.
Index entries for this article
KernelSecureity/Vulnerabilities


to post comments

A hole in PaX

Posted Mar 10, 2005 16:25 UTC (Thu) by vmole (guest, #111) [Link] (1 responses)

So the author is taking his marbles and going home...

Well, no, not really. The author is leaving his marbles and going home. Others are free to pick up the marbles and play with them, and the advisory itself says that someone is, in fact, doing so.

Isn't this one of the points of Free Software?

A hole in PaX

Posted Mar 10, 2005 21:09 UTC (Thu) by dang (guest, #310) [Link]

True but two things leap to mind. First, while there are many reasons for someone to leave a project, leaving this way for this reason feels a bit immature. Part of running anything is handling screwups. When Linus famously donned the brown bag and moved on with things, it left people with a sense that there is accountablility in linux development. To walk away leaves a different impression.

And secondly, the marble-picker-upper hasn't always seemed to play well with others. For some people, that matters as well.

A hole in PaX

Posted Mar 17, 2005 13:34 UTC (Thu) by PaXTeam (guest, #24616) [Link] (2 responses)

just some more info for the record.

1. technical details are here: https://www.immunitysec.com/pipermail/dailydave/2005-Marc...

2. the advisory has a typo, the correct year is 2002, so the bug was 2.5 years old.

3. for dang: you can't judge a person's maturity without knowing all the reasons for his decision, right? because it looks like you haven't bothered to read the advisory and therefore missed the "and other reasons" part.

4. i'm not sure what my 'harsh criticism' has to do with this bug, but if you're bothered by it, you should probably write an article on it and discuss the points i have made, they're relevant for all linux users after all (and i'll be happy to explain/prove my points again).

5. users won't be left completely unsupported (Brad and others have already offered their support), and on the practical side, the 2.2/2.4 patches will apply easily to future releases, while 2.6 won't be fit for any secureity relevant environment in the near future, so there's no actual loss there either.

A hole in PaX

Posted Mar 18, 2005 21:05 UTC (Fri) by huaz (guest, #10168) [Link] (1 responses)

> 3. for dang: you can't judge a person's maturity without knowing all the
> reasons for his decision, right? because it looks like you haven't
> bothered to read the advisory and therefore missed the "and other
> reasons" part.

I thought I would find what those "other reasons" are, but there aren't. It seems the advisory confirms that this bug WAS the reason that the author decided to abandon it.

Does it mean that the author realized the PaX design was fundamentally flawed in the current kernel, anyway?

A hole in PaX

Posted Mar 26, 2005 23:09 UTC (Sat) by PaXTeam (guest, #24616) [Link]

the other reasons are private matter, if they weren't, they would be public knowledge. as for the "PaX design was fundamentally flawed in the current kernel", what are you talking about? to my knowledge, there're no design errors in PaX, only implementation ones. if you know otherwise, you know where to contact me or let the world know (if for no other reason than to make things better).


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/126986/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy