Re: Partial Hardware Protection for Buffer Overrun Exploits

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

Brian Catlin wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
> news:3E9D8AB6.4090009@cogeco.ca...
> 
>>I am curious if anyone has discussed this idea before:
>>
>>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.
>>
>>SUGGESTED HARDWARE SOLUTION:
> [snip]
> 
> An excellent idea.  Unisys implemented this 30 years ago in their 'A series'
> machines; 

I can't say that I am familiar with this hardware, but I sense that
you might misunderstand my suggested approach. I am _not_ suggesting
in _this_ proposal that executed code must be in a read-only
segment (text region), but that the new RETURN instruction only
accept valid addresses in the read-only segments (ie. text region).

I could be wrong, but I suspect that the hardware you speak of
may insisted on a execute (or read-only) attribute, but this is
very different.

All buffer exploits that I know about, plant code in the stack
frame (or perhaps even overrun the frame), and then pass control
to that code by clobbering the return address that has been
pushed on that stack frame. The return address should normally
point to the code (text region), but in the exploit, it points
to the stack frame (data region).

Just insisting that the return instruction only accept a text
region address, would largely eliminate the danger of running
exploit code.

> It seems to me, that the real root of the problem is the C language, and its
> lack of a native string type (and the really crappy run-time library).  While
> these sorts of attacks probably aren't limited to C programs, I'd be willing to
> bet that they are LOTS less prevalent in other languages.  It also seems to me,
> that programming has been made too easy; there are lots of people out there
> writing software that should really be out cleaning toilets instead.
> 
>  -Brian

While I agree that C (and other languages) do present a practical
problem here, I don't see this as the "practical solution". Yes,
it would be nice if UNIX/Linux/FreeBSD and Windows would all be
rewritten in Ada95, and largely eliminate this problem. But do
you really believe that this is going to happen any time soon?

I can't even count on the name servers (bind) and dhcp servers
and client programs to do this yet.

If Intel provided an RETT (return to text) instruction, GCC could
be enhanced to use it, and all of the existing Linux code base
for example, could be strengthened a mere recompile.

The only downside of this approach that I see, is that this might
reduce the pressure for people to critically examine the issue
(ie. move to Ada?) However, there is still the denial of service
aspect, that this won't address anyway.

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