Messages in this thread | | | From | "Robert White" <> | Subject | RE: WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2 | Date | Wed, 9 Jun 2004 13:53:16 -0700 |
| |
Which is why I, later in the same message, wrote:
Architecturally the easy-application-accessible switch should be something more than a syscall to prevent a return-address-twiddle invoking the call directly. I'd make it a /proc/self something, or put it in a separate include-only-if-used shared library or something. If the minimal distance is opening and writing a normally-untouched file then you get a nice support matrix. (e.g. no file means no feature, file plus action means executable stack, no action means system default (old can, new cannot), hacks would require a variable (fd) and executing arbitrary code to open and write that file, programs/programmers that want/need the old behavior can achieve it without having to know how to manipulate their ELF headers or tool-chains, etc.)
Which is not susceptible to the 1-2 attack you mention below because the open and write cannot be done on a protected stack or heap, since it would then have to be (er... ) executed to perform the hack.
Ahhhh, yes...
-----Original Message----- From: Jesse Pollard [mailto:jesse@cats-chateau.net] Sent: Wednesday, June 09, 2004 9:53 AM To: Robert White; 'Ingo Molnar'; 'Christoph Hellwig'; 'Mike McCormack'; linux-kernel@vger.kernel.org Subject: Re: WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2
On Tuesday 08 June 2004 16:50, Robert White wrote: > I would think that having an easy call to disable the NX modification would > be both safe and effective. That is, adding a syscall (or whatever) that > would let you mark your heap and/or stack executable while leaving the new > default as NX, is "just as safe" as flagging the executable in the first > place.
ahhhh no.
The first attack against a vulerable server would be to load a string on the stack that would: 1. have address of the syscall to turn off NX, then return to the stack. 2. have normal worm/virus code following.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |