[4283] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Linux kernel patch to remove stack exec permission

daemon@ATHENA.MIT.EDU (Ingo Molnar)
Mon Apr 14 16:07:19 1997

Date: 	Mon, 14 Apr 1997 16:36:03 +0200
Reply-To: Ingo Molnar <mingo@PC5829.HIL.SIEMENS.AT>
From: Ingo Molnar <mingo@PC5829.HIL.SIEMENS.AT>
X-To:         solar@sun1.ideal.ru
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <199704121603.NAA21137@sun1.ideal.ru>

On Sat, 12 Apr 1997 solar@sun1.ideal.ru wrote:

>                                                   [...] Some buffer
> overflows are still exploitable, by making the program put the shellcode
> somewhere else in its memory space, not on the stack, and overwriting the
> return address to point to that area. [...]

would it be a good idea to strip off the highest bit in env[] and args[]
when exec()-ing? This makes it quite hard to pass shellcode to the
process? We can get this bit cutoff very cheap by trivially modifying
copy_strings() in exec.c. [hm, this breaks 8-bit character sets?]


for the BSS/malloc() things we could theoretically get the kernel to put
executable mmap()-ed areas into the 0-1G range, and the rest into the
1G-2G range. [whee, reinventing segmented memory ...]. As most if not all
code is independent of what type of area mmap() gives us, this seems to be
doable via ext2fs attributes. Then USER_CS would be in the 0-1G range.


but the Right Thing would be if Intel fixed their page protection bits to
honor exec permissions actually ...

-- mingo

home help back first fref pref prev next nref lref last post