Michael Warfield writes:
> You're claiming that it's easier to create executable binaries
> without knowledge of the underlying binaries? Now that's a stretch.
> All you need is gdm and the binary you want to exploit. Gdb will give
> you the two addresses you need and testing is a snap. You don't even
> need to understand assembly language to do it. Set a trap at the entry
> point to the routine you're going to trap and you've got it in the stack
> frame. The address of the system calls take what, about 5 seconds to
> get from gdb?
It's possible (albeit more difficult) to exploit a stack buffer overflow
on an executable stack remotely with no access to the binary that is
being exploited. It's not really feasible to exploit a stack buffer
overflow on a non-executable stack if you don't have access to the
binary being exploited.
> > 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.
>
> No... Ted 'Tso convinced me and I've seen both the proof and the
> demonstration. If you have an executable stack exploit, you are positively
> guarenteeded of at least one exploit, and more than likely many more
> than one, which does not require executable code. I haven't heard of
> a single platform where that was not true. It's even true on Windows. :-)
> I saw one for Windows where the code that was exploited did a copy that
> would only allow printable ASCII. With the non-executable tricks, it's
> a snap since most of what you are passing IS ASCII. That vuln writer
> had to pull the trick of passing his exploit through an sscanf to get
> to some values he needed, but it still worked and he claimed it was less
> than a couple of hours work.
You're just not paying attention here. I fully understand what a
non-executable stack can and can't prevent and how a non-executable
stack can still be exploited. You along with some other people continue
to claim that because a non-executable stack doesn't prevent every
possible exploit, then it provides no protection at all. That argument
is not logic, but mere hyperbole; you can't deny that it does prevent
certain methods of exploitation even though it does allow others. If
you'd at least state your argument as "a non-executable stack doesn't
provide a useful level of protection" rather than the baldly false "a
non-executable stack provides NO protection" then you'd be making sense.
Not to mention that the example you give continues to belie your
assertion that stack buffer overrun exploits against a non-executable
stack are easier than the traditional methods that work against an
executable stack. Having to write an all-printable-ASCII exploit that
has to go through an sscanf() is _easier_ than the old way?
Believe me, I've been through this argument before. I wouldn't mind so
much if the discussion was about whether a non-executable stack provides
enough protection to make it worth going into the kernel, and I
understand the people who argue that it's too much of an ugly kludge to
implement on the x86. But please, quit trying to claim that a
non-executable stack provides absolutely no protection.
-
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:14 EST