[rescue] A perverse thought (SGI security division)

[Nathan Raymond]

On Fri, 12 Mar 2004, Dave McGuire wrote:

> On Mar 12, 2004, at 12:05 PM, Clayton Wheeler wrote:
> > Recent versions of OpenBSD actually have pretty nice security features
> > at the kernel and C runtime level. It makes sure that writable pages
> > are not executable, and vice versa, to prevent buffer overflows from
> > inserting code successfully; Solaris and some other OSs do this to
> > some extent. However, OpenBSD also puts guard words (or something)
> > around stack frames, so programs will be terminated if they clobber
> > the stack. And I think the most recent version loads shared libraries
> > in random order and at random offsets, so hostile inserted code can't
> > make assumptions about where (for example) libc is found.
>
>    Holy cow, I'm impressed by this.  I need to read up on this a bit
> more.  It seems that, nowadays, OpenBSD has come a bit further than
> copying the NetBSD source tree, adding a new SCSI driver, and changing
> all the copyright notices.
>
>    Since at least release 2.7 or maybe even 2.6, Solaris has had
> facilities to prevent the execution of code from the stack, and to log
> any attempts to do so.  It does this by marking the memory pages used
> for the stack as non-executable and catching the traps.  To enable
> this, add the following lines to /etc/system and reboot:
>
> set noexec_user_stack = 1
> set noexec_user_stack_log = 1
>
>    Note that, as far as I'm aware, this doesn't work in sun4c machines
> due to missing hardware support...but running Solaris on sun4c machines
> is asking for trouble (or at least extended periods of boredom while
> you wait for things to finish) anyway.

I imagine SPARC (and perhaps most RISC architectures) + OpenBSD must be a
fairly excellent combination, considering how SPARC alone is more
difficult to exploit than, say, x86:

http://ouah.kernsh.org/UNF-sparc-overflow.html

"6 - Conclusion
We need a bit more luck to be able to exploit Sparc buffer overflows than
their brothers/sisters on x86. In general it is not enough to be able to
overwrite just a few bytes of the buffer. Additionaly we saw that the way
the stack is handled has a great influence on the exploitability issue of
its buffer overrun vulnerabilities. This class of vulnerablities can not
always be exploited on Sparc as there must exist at least one level of
subroutine calls nesting, so that two concurrent ret/restore pairs can be
executed by a vulnerable program after its stack got overrun."

--
Nathan Raymond