Re: Partial Hardware Protection for Buffer Overrun Exploits

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Vinzent Hoefler wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote:
> 
>>If it is possible for the CPU to distinguish between the
>>"text" region and the "data" regions (including stack),
> 
> It does in some way. But in the flat model it does not distinguish the
> addresses. So if you say CS:[03FC7687] and SS:[03FC7687] it refers to
> the same memory, although the access rights are different depending on
> how you access it. That is the danger.

Actually, the flat memory model does not have to be a
show stopper here. The _CPU_ must translate every VM
address into a physical real address. In this process,
the CPU is quite capable of identifying that the address
is at least (read-only), and perhaps that it is text
(or could be enhanced to do so).

IIRC, Intel doesn't have an "execute" flag for segments,
but if they were to add that, I think the situation can
be further improved.

>>then
>>a new instruction (say RETT - Return to Text), could cause
>>a fault to occur, if the return address is not to a text
>>virtual memory address (for exploits this address points
>>to a "data" region, and usually part of the current stack
>>frame).
> 
> There is already an easier solution (at least for x86-CPU's): Don't
> use a purely flat model, with this I mean, you shouldn't use the same
> address space for both data/stack and code. This could already be
> accomplished with the standard protection/paging features of the x86.

I don't follow this. Even if you divide data and stack, how
does this help? The return instruction is what needs to be
restricted in what is acceptable to it. Since you can't change
the current RET instruction without breaking code, I propose
they add a RETT instruction that does insist on
restrictions. Even the simple restriction that the return
address is read-only, would help.

> Unfortunately there are some features in current real world compilers
> (like for instance, the so-called trampolines) that require an
> "executable" stack segment. Simply get rid of these features and the
> solution is easy.

By adding a RETT instruction, we are _not_ taking away the
priviledge of running code in data/stack regions. As you've
pointed out, there may be good reasons to execute code in
the data region (like JIT compilers).

I just want to restrict the normal case of the RET for a
function, so that it cannot give control to arbitrary hostile
code.

>>As far as I see, the only way to exploit buffers would
>>then require the attacker to find usable sections of text
>>to do his bidding.
> 
> Because you cannot write to the code segment without triggering a GPF
> it would be simply impossible. Still, you could launch a DoS-attack
> this way.

In a large enough process, an attacker might be able to find
a sufficient number of bytes of code that does just what he
wants. If he can find a text sequence that does a jump to
register for example, all he then has to do is to arrange
the clobbering of the stack frame such that that register
has the required address he wants.

This is why I hesitate to say that this approach would be
foolproof. I still believe however, it is one step in the
right direction.

>>There has to be a better solution to the current crop of
>>buffer exploits, that are being used daily.
> 
> Yes. What about using Ada? ;-)
> 
> Vinzent.

This is the area where I think many people are missing the
point.  Yes, indeed, programming and programming tools can
help, and programmers need to do a better job. I agree with
this entirely, and I fully support the use of Ada in this
respect.

But the _practical_ reality is that we will be using C based
operating system, applications, drivers and desktops for
a long time to come. These will be always susceptible to
exploits. Why?

   - human limitations (or human nature)
   - failure to accept better tools
   - failure to properly apply better tools
   - failure in programming discipline
   - the drive to get the product out first

and probably many more reasons.

While I disagree with using a 8 inch spike in the living
room wall to hold up a picture (my father was like this),
doesn't it make sense to address the problem once and for
all, if the options are presented? I like to fix the
problem once, and be done with it. While the proposal
is not the final answer here, it is a _big_ step forward
I think. One that we won't have to backtrack on. We will
later have to address the other exploits (like the jump
to register one), but at least that entire "class" of
exploits is forever gone.

We can all talk about how it "should be". But I want to
see a real solution. A real improvement. I don't want to
wait 10 years for it either. We need to be looking at
other creative ways to deal with this problem.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg