Re: Partial Hardware Protection for Buffer Overrun Exploits

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

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

> I've already acknowledged this fact, in an earlier post.

True.  But you didn't acknowledge the consequence given the "weakest
link in chain" issue.

> > I also think you underestimate the danger of jumping into existing
> > read-only code.
> 
> Whether or not I am "underestimating" is not important. I have
> however, already pointed out the danger of exploiting some
> existing "code" in the "read-only" region.  But what point
> are you making here?

I was trying to make the "weakest link in chain" point.

> Based upon your response, it seems to be something like "we
> shouldn't make any hardware change", to which, I have to
> disagree.

Well, "we" as in "you and me" aren't making any changes to the Intel
hardware architecture, as far as I know.  ;-)

But, yes, I'm saying there's no point in making hardware changes that
will fix only part of the problem.  I admit that my opinion might be
colored by a "purist" attitude: the "right" solution is array bounds
checking done in software.

> > When it comes to security (as opposed to normal run-of-the-mill bugs),
> > the chain is only as strong as its weakest link.
> 
> This part I agree with (at least in the long run).

OK.  But note that hardware changes are necessarily "long run".

> >  So if you close 99% of
> > the holes, you don't prevent anywhere near 99% of the problems.
> 
> Looking at the larger picture, I disagree slightly. Yes, in the
> long run, this will be the result if the issues are not all
> addressed.
> 
> In the short term however, you _do_ eliminate an entire class
> of problems. This can be useful, for several reasons:
> 
>    i)  to buy time, in order to address the other 1%

Shrug.

>    ii) to make writing exploits so difficult, that the script
>        kiddies won't bother any more (ie. fewer exploits are
>        in the wild)

I don't know much about "script kiddies", but I was under the impression
that they can bring sophisticated technology to bear, via scripts, even
if they don't understand much.

>    iii) Some programs may not actually have that 1% vulnerability,
>        and so they might represent a class of programs that can
>        be trusted (ideal if this includes servers on the net side).

Well, if you mean programs that don't need write access to executable
memory, then I agree there's a reasonable class of such programs.
If you mean programs that don't do indirect jumps/calls, then no.

>    iv) get people and CPU engineers thinking along this line
>        to come up with other innovative solutions.
> 
> For example, there's no reason that a jump to register instruction
> cannot be limited to text only code.
> 
> > 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.
> 
> I entirely disagree that this needs to "slow down" anything. If anything,
> a soft approach is slower(!). The CPU already must translate a virtual
> address (of any kind), and by the time the real address goes out to
> the cache and to memory, the information necessary for read-only (or not)
> is already known by the CPU. All it needs to do is test that flag
> (one entire bit, mind you ;-), and choose to accept the address or
> abort.

Yeah, I guess you're right on this point.  What you need is protection
bits that express executable-but-not-writeable, and corresponding OS
support.  But I still say, the "chain links" thing is important.
One must at least address all indirect jumps, not just return
instructions.

- Bob