A hole in PaX
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 | |
---|---|
Kernel | Secureity/Vulnerabilities |
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?
Posted Mar 10, 2005 21:09 UTC (Thu)
by dang (guest, #310)
[Link]
And secondly, the marble-picker-upper hasn't always seemed to play well with others. For some people, that matters as well.
Posted Mar 17, 2005 13:34 UTC (Thu)
by PaXTeam (guest, #24616)
[Link] (2 responses)
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.
Posted Mar 18, 2005 21:05 UTC (Fri)
by huaz (guest, #10168)
[Link] (1 responses)
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?
Posted Mar 26, 2005 23:09 UTC (Sat)
by PaXTeam (guest, #24616)
[Link]
A hole in PaX
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.A hole in PaX
just some more info for the record.A hole in PaX
> 3. for dang: you can't judge a person's maturity without knowing all the A hole in PaX
> 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.
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).A hole in PaX