Re: Partial Hardware Protection for Buffer Overrun Exploits

[Vinzent Hoefler <ada.rocks@jlfencey.com>]

"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.

>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.

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.

Well, it would make the writing of self-modifying code a little bit
harder.

>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.

>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.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.