Re: Partial Hardware Protection for Buffer Overrun Exploits

["Brian Catlin" <brianc@sannas.org>]

"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; however, getting this to work on a more conventional processor
architecture (the Unisys machines are stack-based, and no assembler is sold for
them, just high-level languages) would be rather difficult, I suspect.  The
beauty of allocating space on the stack for strings, is when the routine
returns, the storage is automatically returned.  A software-only solution could
be implemented purely in the compiler, by allocating the string storage on the
heap (with guard pages around it), and then deallocating everything when the
routine returns.  This would impact performance, but would also make the system
less vulnerable to this particular attack.

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