RE: WINE + NX (No eXecute) support for x86, 2.6.7-rc2-bk2

[Robert White]

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@xxxxxxxxxxxxxxxx] 
Sent: Wednesday, June 09, 2004 9:53 AM
To: Robert White; 'Ingo Molnar'; 'Christoph Hellwig'; 'Mike McCormack';
linux-kernel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/