Re: Partial Hardware Protection for Buffer Overrun Exploits

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> REVIEW:
> 
> Buffer exploits work of course, by allowing the attacker to
> overwrite a buffer (array) with hacker code to be executed.
> Part of this exploit includes the necessity of overwriting
> the return address on the _stack_ frame, that the current
> function will use when it exits (opcode RET?  My assembly
> knowledge is admitedly (for Intel) is very rusty).
> 
> The RET instruction is how control is being given to planted
> "hacker code". Obviously, this is _not_ what we want
> happening on Internet exposed machines.

Overwriting the return address is probably the easiest way to gain
control, but there are lots of other writeable locations containing
addresses that will be jumped to, so the RET/RETT instruction is not the
only problem.
I also think you underestimate the danger of jumping into existing
read-only code.

When it comes to security (as opposed to normal run-of-the-mill bugs),
the chain is only as strong as its weakest link.  So if you close 99% of
the holes, you don't prevent anywhere near 99% of the problems.

It's a RISC vs CISC thing.  The RISC approach is to do bounds-checking
in software, and this has been well understood for decades (since before
RISC was invented).  So it's pretty annoying to have a hardware-based
solution, which slows down all returns (and all indirect jumps and
calls, I would claim) just because the industry is unwilling or unable
to use reasonable programming languages.

Your question is really a hardware architecture issue, so you might want
to post it to comp.arch.  In fact, I think if you search the archives,
you'll find similar ideas proposed there.

- Bob