Re: Solaris 7 x86 lpset exploit.

[Casper.Dik () HOLLAND SUN COM (Casper Dik)]

> echo "noexec_user_stack/W 0x1" | adb -wk /dev/ksyms /dev/mem
> echo "noexec_user_stack_log/W 0x1" | adb -wk /dev/ksyms /dev/mem

This only works in Solaris 7 or later; Solaris 2.6, for some reason,
only enables this setting at boot.

For earlier releases (2.5.1), there's the script "protect_stack" that
you can find in the Bugtraq archives.   The script only works on
sun4m/sun4d systems as none of the other systems implement execute
permissions properly (they equate read and execute).  The script
also changes execute permissions on all BSS pages, and that is known
to break a large set of programs (Lisp runtime, Java w/ JIT, etc).
The kernel option has no such problems.

> another note: while this seem to have very litle negative effect
> on all solaris/sparc app's i have used so far, there is a reason,
> why SUN does enable stack execution by default, if i am correctly
> informed this is due to some fortran or rare/old compiler issue,
> and might break some fortran or other alien language code...

Well, the official reason is "the ABI requires the stack to be
executable".  This is not true for 64 bit processes, so those get
a nonexecutable stack by default.

I've not heard of shrink-wrap applications that break; gcc's trampolines might
fail, but that's fixed in later releases of gcc.  Also, gdb depends on
an executable stack for some of the things it does.

> Thats probably what the second line (noexec_user_stack_log) is
> for, to see in your kernel-log's when this caused a program to fail.

Which is very useful to find attacks in progress as well as programs
that need an executable stack.

Because most people run w/o noexec_user_stack set, common exploits
will fail if it is set.  Exploits are still possible, but it appears
that more variables need to be guessed right than just the stack offset.
I.e., the exploit will be harder to write and harder to run (but not
impossible)

Casper