[Fwd: Simple OS Security Idea]

[Fwd: Simple OS Security Idea]

[Bruce Blodgett]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

GCC developers,

Although my background is in compilers, I'm not up on the current
nuances and ramifications of nonstandard calling conventions, so I don't
feel qualified to modify GCC myself.  However...

My goal is to get the idea below across to more people.  Please forward
my original message to all appropriate parties.  I just ask that you cc:
blodgett@mitre.org when you do so.  Thank you.

--- Bruce

Richard Stallman replied:
...
> As for why this calling convention is not used, that is partly because
> GCC supports the standard calling convention of each machine.  To use
> a nonstandard calling convention is rather a pain.
> 
> But it is not impossible.  If someone wants to do it, I guess that
> implementing the nonstandard convention in GCC would be the first
> step.
> 
> If you are interested in working on it, please write to gcc@gcc.gnu.org.

-------- Original Message --------
Date: Mon, 16 Jul 2001 18:28:24 -0400
From: Bruce Blodgett <blodgett@mitre.org>
To: rms@ai.mit.edu

Hello.

I'm concerned about the current lack of security in today's operating
systems and core applications.  I have an idea that seems obvious to me,
and am looking for help in communicating it to those who can implement
it.

Given that buffer overflows account for a huge number of exploits:

Why don't the OS developers simply compile their code in such a way that
all (currently stack-based) buffers and (currently stack-based) return
addresses are allocated in unrelated separate storage areas?  (Then,
knowing one address would be of no use in determining the other, so
overflowing a buffer could not overwrite the return address).

I find it hard to believe that the current Vulnerable Stack Layout (VSL)
is the only efficient layout.  If there exists a NonVulnerable Layout
(NVL) that is similarly efficient, I find it surprising that compiler
writers still implement today's VSL.

Even if the best NVL sacrifices a little efficiency for the sake of
security, I'm surprised that NVL isn't the default.  The more efficient
VSL could still be used whenever the compiler can guarantee (or the
aggressive user switch promises) that the resulting generated code is
not vulnerable to buffer overflow attacks.

Bruce Blodgett
Mitre Corporation
(781) 271-7813

P.S. Any ideas regarding implementation of an efficient NVL?

P.P.S. How can I spread this idea to those who can effect this change?
S/MIME Cryptographic Signature


[-- Attachment #2: smime.p7s --]
[-- Type: application/octet-stream, Size: 1735 bytes --]