> 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.
>
For some time - yes, not in long terms.
> 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.
>
What you need is just jump on value stored in register to do this. Sucn
change is not a big problem for scilled cracker. Once unexecutable stack
will be default all downloadable exploits will be modified accordingly in
no time at all while trampolines, XFree86 and so on will suffer...
-
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/