Partial Hardware Protection for Buffer Overrun Exploits

Partial Hardware Protection for Buffer Overrun Exploits

[Warren W. Gay VE3WWG]

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:

For UNIX/Linux anyway (and I think for Win32 also), the
code is in protected segments that are at least "read only"
and on some platforms perhaps even marked "executable". In
UNIX terms, this represents the "text" area of an executable.
This means that _normally_, the return address should only
refer to text region addresses.... (or alternatively,
"read-only" regions of virtual memory).

If it is possible for the CPU to distinguish between the
"text" region and the "data" regions (including stack), 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).

Then GCC could be enhanced to replace the dangerous RET
instruction with the safer RETT (say) instruction, and one
large class of exploits would be foiled in newly compiled
code. This does not of course fix the denial of service
problems with overruning buffers, but that is another
matter. At least we eliminate the ability of the
attacker to execute planted 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. I suspect that this would make the
attack considerably more difficult, and perhaps in many
cases, impossible or not worth pursuing.

YOUR FEEBACK?

Has this been discussed before?  Is Intel listening?

There has to be a better solution to the current crop of
buffer exploits, that are being used daily.

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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Vinzent Hoefler]

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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Brian Catlin]

"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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Bob French]

"Brian Catlin" <brianc@sannas.org> wrote in message
news:b7ka8l$bs6$1@slb6.atl.mindspring.net...
> "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:
> >
> [snip]
>
> 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

The problem isn't really the string type.  In C parameters for a subroutine
get pushed on the stack.  Must have read/write access.  The call instruction
pushes the return address.  Must have read/write access.  In the beginning
of the subroutine initialized local variables get pushed on the stack and
uninitialized variables have space allocated by moving the stack pointer
according to their size.  Must have read/write access.  Either string or
array or struct missapplied can step on that return address stored right in
the middle of read/write data.  The stack has other return addresses to
caller of the caller, etc.

The data on the stack can also contain a pointer to code.  A sort routine
can be passed the address of the routines that compare a pair of items and
swap a pair of items.  It isn't just return addresses that can be problems.

The call instruction in the write protected TEXT segment is safe.  The real
problem is that programmers fail to check necessary limits.  That isn't to
say that the checking is trivial.  If a string space (array of chars) is
allocated on the stack and passed to a subroutine there needs to be a limit
passed, or a constant limit, and the limit must be less than or equal to the
size of the array as allocated by all callers.

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

Languages that allow the use of a pointer to memory have the issue.  Intel
x86 got the bounds checking instruction back in the days of 80186 but the
subroutine may not know the size of the buffer it is working with.  It seems
that information hiding happens.

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

Bob

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Warren W. Gay VE3WWG]

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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Warren W. Gay VE3WWG]

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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Robert A Duff]

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

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

Overwriting the return address is probably the easiest way to gain
control, but there are lots of other writeable locations containing
addresses that will be jumped to, so the RET/RETT instruction is not the
only problem.
I also think you underestimate the danger of jumping into existing
read-only code.

When it comes to security (as opposed to normal run-of-the-mill bugs),
the chain is only as strong as its weakest link.  So if you close 99% of
the holes, you don't prevent anywhere near 99% of the problems.

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.

Your question is really a hardware architecture issue, so you might want
to post it to comp.arch.  In fact, I think if you search the archives,
you'll find similar ideas proposed there.

- Bob

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Robert A Duff]

Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

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

Well, on any machine that has an "executable" protection bit on each
page, you (the OS) can simply make sure all executable memory is
read-only.  No need for the x86 segmentation junk.  But as you and
others say, that disallows all kinds of useful stuff like trampolines
and self-modifying code (JIT compilers and the like).

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

Amen.

- Bob

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Randy Brukardt]

Warren W. Gay VE3WWG wrote in message <3E9ED2E7.80807@cogeco.ca>...
>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).


That's equivalent to saying that the stack not be marked as executable
code. And it shouldn't anyway, I think it is idiotic that any modern OS
uses a model with no separation of code and data.

Janus/Ada for the Pharlap DOS Extender always did this. The Intel
processor only allows Read-Execute and Read-Write access to segments
(but not both). The DOS Extender (and Windows and Linux do this too) get
around this 'limitation' by providing mirrored segment values that point
at the same memory. What our DOS Extender compiler did was to allocate
the real data area using an OS call, then replaced all of the writable
segment descriptors with the one from the allocation -- including the
stack. (That was a bit tricky!). Then, it was impossible to write the
code segment or execute the data segment without a trap. That caught
plenty of bugs in the implementation of the compiler.

This is such an obvious idea that it's getting implemented in BSD. I saw
this article yesterday:

http://news.com.com/2100-1002-996584.html

My only question is why they didn't do this years ago. The Intel
hardware has always supported it...

            Randy.

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Warren W. Gay VE3WWG]

Robert A Duff wrote:
> "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:
>>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.
> 
> Overwriting the return address is probably the easiest way to gain
> control, but there are lots of other writeable locations containing
> addresses that will be jumped to, so the RET/RETT instruction is not the
> only problem.

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

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

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

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

>  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%
   ii) to make writing exploits so difficult, that the script
       kiddies won't bother any more (ie. fewer exploits are
       in the wild)
   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).
   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.

> Your question is really a hardware architecture issue, so you might want
> to post it to comp.arch.  In fact, I think if you search the archives,
> you'll find similar ideas proposed there.
> 
> - Bob

Even better! Let's have Intel/AMD/IBM implement it in hardware. If
people start asking for it, then maybe we'll actually get workable
solutions.

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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Warren W. Gay VE3WWG]

Randy Brukardt wrote:
> Warren W. Gay VE3WWG wrote in message <3E9ED2E7.80807@cogeco.ca>...
> 
>>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).
> 
> That's equivalent to saying that the stack not be marked as executable
> code. And it shouldn't anyway, I think it is idiotic that any modern OS
> uses a model with no separation of code and data.

For most of _my_ code, that is probably true. However, JVM types
of processes may disagree. They need to be able to assemble
code on the fly and then give them control.

However, I think you could regulate this with some "per thread/process
flag".

> Janus/Ada for the Pharlap DOS Extender always did this. The Intel
> processor only allows Read-Execute and Read-Write access to segments
> (but not both). The DOS Extender (and Windows and Linux do this too) get
> around this 'limitation' by providing mirrored segment values that point
> at the same memory. What our DOS Extender compiler did was to allocate
> the real data area using an OS call, then replaced all of the writable
> segment descriptors with the one from the allocation -- including the
> stack. (That was a bit tricky!). Then, it was impossible to write the
> code segment or execute the data segment without a trap. That caught
> plenty of bugs in the implementation of the compiler.

I would have thought that Linux/FreeBSD/Windows would have been taking
advantage of this already. Is it true that "text" is not read
only there?  What a waste if they make that RW(!)

> This is such an obvious idea that it's getting implemented in BSD. I saw
> this article yesterday:
> 
> http://news.com.com/2100-1002-996584.html

I don't think much of the "random placement" idea, though I
supposed they are being forced to deal with a problem that should
be fixed in hardware (IMHO).

> My only question is why they didn't do this years ago. The Intel
> hardware has always supported it...
> 
>             Randy.

Yes, indeed.  In fact, it might be useful to go one step further,
and add an execute bit (I am under the impression Intel doesn't
make this distinction).  Then you could distinguish between
RO constants and X code.

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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[tmoran]

  Are there exploits using an overflow into a tagged type jump table?
  When Intel came out with Protected Mode Bill Gates declared it "brain
dead" and they came up with the "solution" of doing a restart of the CPU
to shake off the shackles of protection.
  Are there OSes in use that use the Intel protection mechanisms?

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Robert A Duff]

"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

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Frank J. Lhota]

<tmoran@acm.org> wrote in message news:qRVoa.554917$3D1.304762@sccrnsc01...
>   When Intel came out with Protected Mode Bill Gates declared it "brain
> dead" and they came up with the "solution" of doing a restart of the CPU
> to shake off the shackles of protection.

The first Intel chips that supported protected mode were the rarely-used
80186 and the 80286 chips that powered the IBM PC/AT. These early chips
supported a command for transitioning from real to protected mode, but no
simple command for transitioning back to real mode. This is what earned
these chips the "brain dead" assessment from Gates. The lack of a quick way
to get back to real mode was a problem for MS, who wanted protected-mode
extensions to DOS (such as Windows 3.x and OS/2 1.x) to be able to use the
real mode I/O kernel of DOS. Their solution was the "mini-reboot" of the
CPU, for which they paid a performance penalty.

All of these problems went away with the next generation of Intel chips (the
80386 and beyond), which can quickly toggle between real and protected
modes.

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Robert A Duff]

"Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes:

> The first Intel chips that supported protected mode were the rarely-used
> 80186

The 80186 did not support protected mode.  It was practically identical
in architecture to an 8086 or 8088.  The 80186 had a small number of
additional instructions -- e.g., pushall for pushing all registers, I
think (for some definition of "all").

It was used in mainly in embedded systems, I believe.

>... and the 80286 chips that powered the IBM PC/AT. These early chips
> supported a command for transitioning from real to protected mode, but no
> simple command for transitioning back to real mode. This is what earned
> these chips the "brain dead" assessment from Gates. 

Well it *was* pretty brain dead, for this and other reasons.

>...The lack of a quick way
> to get back to real mode was a problem for MS, who wanted protected-mode
> extensions to DOS (such as Windows 3.x and OS/2 1.x) to be able to use the
> real mode I/O kernel of DOS. Their solution was the "mini-reboot" of the
> CPU, for which they paid a performance penalty.
> 
> All of these problems went away with the next generation of Intel chips (the
> 80386 and beyond), which can quickly toggle between real and protected
> modes.

Right.  In fact, the 80386 introduced "virtual 8086 mode", which allows
multiple real-mode virtual 8086 machines running on the same machine.

- Bob

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Ed Falis]

On 22 Apr 2003 17:15:09 -0400
Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> The 80186 did not support protected mode.  It was practically
> identical in architecture to an 8086 or 8088.  The 80186 had a small
> number of additional instructions -- e.g., pushall for pushing all
> registers, I think (for some definition of "all").

It also had bank-switching of memory, but that doesn't quite qualify as
"protected mode".

> 
> It was used in mainly in embedded systems, I believe.
> 
> >... and the 80286 chips that powered the IBM PC/AT. These early chips
> > supported a command for transitioning from real to protected mode,
> > but no simple command for transitioning back to real mode. This is
> > what earned these chips the "brain dead" assessment from Gates. 

Yeah, but that brain-dead design actually allowed the first Ada compiler
on a PC. ;-)

- Ed

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Randy Brukardt]

Ed Falis wrote in message
<20030422171827.6fb01e6d.falis@adelphia.net>...
>Yeah, but that brain-dead design actually allowed the first Ada
compiler
>on a PC. ;-)


Humm, Janus/Ada never needed (or used) the 80286 protected stuff. We
still have versions of Janus/Ada 83 that run in 640K on MS-DOS; early
partial versions ran in much less memory (the 256K that was common in
the early days of the PC).

The early Telesoft and Supersoft compilers also ran on basic 8086's. So
what are you talking about?

          Randy.

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Ed Falis]

On Wed, 23 Apr 2003 21:00:46 -0500
"Randy Brukardt" <randy@rrsoftware.com> wrote:

> The early Telesoft and Supersoft compilers also ran on basic 8086's.
> So what are you talking about?

The Alsys compiler, which I'm pretty sure preceded those.

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Randy Brukardt]

Ed Falis wrote in message
<20030424094805.1cb53bd1.falis@adelphia.net>...
>On Wed, 23 Apr 2003 21:00:46 -0500
>"Randy Brukardt" <randy@rrsoftware.com> wrote:
>
>> The early Telesoft and Supersoft compilers also ran on basic 8086's.
>> So what are you talking about?
>
>The Alsys compiler, which I'm pretty sure preceded those.

Humm, the early Janus/Ada and Supersoft Ada ran on CP/M on Z-80's,
certainly before the 80286 was even invented. And we had Janus/Ada on
the PC in early 1982, and was well before the AT was introduced. (We had
one of the original PC/XTs, complete with sticker about not unpacking
before the introduction date [IBM had sent one to each dealer for
display purposes before the introduction of the XT.] - it's serial
number was something like 20000000003468.)

One can argue about what exactly consistutes an Ada compiler, but I know
Janus/Ada was out long before there even was an 80286, and we had
competitors at that time.

(And, if I still had that PC/XT, Janus/Ada 83 for MS-DOS would run on it
and compile and run the entire ACVC 1.11 test suite on it. We did
validate compilers on that machine under 1.9 and 1.10. So there
certainly is no need for a 80286 to implement a usable Ada 83.)

          Randy.

Re: Partial Hardware Protection for Buffer Overrun Exploits

[Ed Falis]

On Thu, 24 Apr 2003 13:42:51 -0500
"Randy Brukardt" <randy@rrsoftware.com> wrote:

> One can argue about what exactly consistutes an Ada compiler, but I
> know Janus/Ada was out long before there even was an 80286, and we had
> competitors at that time.

I think validation was the definition, and it wasn't arguable.
- Ed