lkml.org 
[lkml]   [1999]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Unexecutable stack
Steve VanDevender wrote:
>
> Richard B. Johnson writes:
> > The notion of a secure stack implies that you get some kind of security
> > by making the stack non-executable. This theory has, to the best on
> > my knowledge, never been shown to have merit, much less proof. The
> > old games of loading executable opcodes into local data on the stack,
> > overwriting the return address with that data (to point to the code
> > you want to execute), then causing an exception (stack overrun) to
> > make it happen, are not something you could encounter with the current
> > network daemons.
> >
> > You would need a local account, with root access, to even experiment.
>
> I run a couple of large Solaris 7 systems with the
> "noexec_user_stack" option enabled. This defeats nearly all root
> exploits based on stack overflows; I've tried them and intruders
> have tried them without success. Making the stack non-executable
> really does help.
>
> You don't quite seem to understand the mechanism of stack buffer
> overflow exploits. The buffer overflow does not cause an
> exception; it merely overwrites the return address in the current
> stack frame and places some additional executable code in the
> stack area that the overwritten return address now points to
> (often, this code is padded liberally with no-op instructions so
> that the precise location of the executable code is less
> important). This is still possible with network daemons although
> most commonly-used daemons tend to be more carefully written to
> avoid buffer overflows these days (sadly, not as many as ought to
> be).
>
> However, the most common target of buffer overflow exploits are
> setuid-root binaries. Even though local access is generally
> needed to exploit those, it is common on large systems for
> intruders to find accounts with weak passwords or sniff account
> passwords elsewhere in the network to gain that access.
>
> In theory it is possible to write executable code into a buffer
> in the data segment and overflow a buffer in the stack so that
> the stack frame contains a return address that points into that
> data. In practice it is much harder to create an exploit with
> this method as it requires quite detailed knowledge of the data
> segment layout.

Stack smashing requires usually exactly the same "detailed knowledge of
the data
segment layout" alredy now too. Have a look at the prominent mountd
or the wuftp exploints for example. This is due to the fact that
those attacs are targeting globals, which will get very different
addresses due to general data aligment particular to the special
compiler version used.

--Marcin Dalecki

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.172 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site