Michael H. Warfield writes:
> I'm not arguing against any other layer than just the non-executable
> stack option. Some would argue that it provides less than a defense simply
> because it provides a sham or an illusion of a defense when the attackers
> really know better. I'm not sure I totally agree with that position, but
> I do know, now, that it offers zero protection. It closes no holes and
> provides no increased difficulty in exploit creation or deployment. None.
> Zero. Worthless.
If it's really so much easier to create a stack overrun exploit that
points a return address to the code to issue a system call in the text
segment, why have all the script kiddies been wasting their time making
stack overrun exploits that put the code into the stack buffer instead?
It's true that you can create a stack overrun exploit that points the
stack frame return address into the text segment, but I think it's a
stretch to claim that it's much easier to make that work compared to the
traditional exploits. The reason that it's been easier to create
traditional exploits that overwrite a stack buffer with appropriate
executable code is that they work without having to know any details of
the binary that is targeted and such exploits can be easily tested and
applied remotely via the network; one finds a binary that has a buffer
overrun that's invocable from the network, and tries a few different
overrun strings with different offsets and padding. In fact, the same
exploit technique can be applied to a lot of different programs with
very little change.
And it's just hyperbole to claim that a non-executable stack offers _no_
protection at all; you can only do so in complete ignorance of the
systems that do use a non-executable stack that do resist common
exploits.
-
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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:13 EST