[3480] in cryptography@c2.net mail archive
Re: Medium-term real fix for buffer overruns
daemon@ATHENA.MIT.EDU (Tom Perrine)
Thu Oct 15 01:10:40 1998
Date: Wed, 14 Oct 1998 21:57:45 -0700
From: Tom Perrine <tep@SDSC.EDU>
To: karn@qualcomm.com
CC: smb@research.att.com, gnu@toad.com, reinhold@world.std.com,
decius@ninja.techwood.org, karn@qualcomm.com, cryptography@c2.net
In-reply-to: <199810150237.TAA29923@servo.qualcomm.com> (message from Phil
Karn on Wed, 14 Oct 1998 19:37:54 -0700 (PDT))
>>>>> On Wed, 14 Oct 1998 19:37:54 -0700 (PDT), Phil Karn <karn@qualcomm.com> said:
>> Today's offenders are strcat, strcpy, sprintf, and the like. Few programs
>> use gets anymore -- after all, that was the problem, so people took it
>> out of their code, and didn't bother to think further...
Phil> Good point. Arguably these functions should be expunged too, in favor
Phil> of strncat, strncpy, etc.
Phil> I agree with Perry that the better solution in the long run is to
Phil> switch to a language like Java or Perl that manages memory
Phil> automatically and carries the length of an object in the object
Phil> itself. This, and Perl's taint checking feature, nicely eliminate a
Phil> whole class of bugs that just seem to keep coming back in C.
The great thing about "computer science" is that we are free to
re-invent everything, about every 10-20 years.
We *had* languages where the "sized string" was a first class
datatype. Lots of them. They were all killed off by those who
claimed that they were too complex (PL/1), or too inefficient
(Pascal), or too "non-standard" (Algol, Jovial, etc.) I'm sure others
can remember more languages that could qualify.
Some claimed that higher-level (higher than "C") languages did not
have the right features to do OS development. I offer Multics (PL/1),
CP-6 (PL6) and Burroughs's OS as worked examples. These systems
failed for market reasons, not because they were written in
inappropriate languages.
When I was an intern in the early 80s, my mentor at Honeywell made me
read all the security papers from the late 60s on security and
integrity, especially with regard to operating systems design,
penetration testing, and actual intrusions.
The *primary* method for evading or defeating the protections of the
OS was what we would refer to today as a buffer overflow: manipulating
the buffers (size or location) of the system calls from user space
into privileged space. This was generically referred to as the
"argument validation" problem.
These days, we have to remember that anything which runs with any
non-user privileges is really part of the OS (or the TCB, if you
prefer), and should be subject to the same examination as the rest of
the kernel. A buffer overflow is not bad. A buffer overflow in
trusted code is bad.
At that time (late 60s through late 70s), *all* OS research activities
agreed that at least part of the answer was writing OS code in better
languages. Since the language of choice at the time was assembly,
*any* language would be better (or so we thought).
The language of choice would have proper bounds checking on all data
types, with this enforced either by run-time code generated by the
compiler, or in some cases, by more complex instructions in the
hardware itself. Several architectures were designed and implemented
with varying levels of hardware assist for bounds checking: everything
from simple "bounds checking instructions" to full-on
"object-oriented" instructions with the bounds of an object defined by
a descriptor which could not be stepped-out of (think "real segments"
with permissions at segment level the same .
Of course, UNIX, C, and RISC came along and the rest, as they say, is
history.
Don't get me wrong, I think that all three of these were necessary in
order to introduce other concepts into our world: software
portability, *people* portability, affordable commodity hardware, etc.
But I digress....
Phil> Interpreted languages do worry me a little because of the potential
Phil> for bugs in the interpreter itself, which has to run as a highly
Phil> trusted piece of code.
You have to either trust the interpreter, or the compiler. Or the
hardware. Or the design, for that matter.
Phil> Perl is the first language I've found to be worth learning since I
Phil> learned C in 1978. There are certainly *many* ugly things in Perl, but
Phil> the automatic memory management is really quite nice.
PERL wouldn't be all that great for OS work. I'm thinking of a subset
of PERL that could be compiled, or the compiled variant of PYTHON.
Or PL/1 :-(
--
Tom E. Perrine (tep@SDSC.EDU) | San Diego Supercomputer Center
http://www.sdsc.edu/~tep/ | Voice: +1.619.534.5000
I'm not a Randian, an Objectivist, or a big-L libertarian. Sometimes
I'm not a little-l libertarian, either. I'm just Reasonable.
