Re: Partial Hardware Protection for Buffer Overrun Exploits

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

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