[3494] in cryptography@c2.net mail archive
Re: Medium-term real fix for buffer overruns
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Fri Oct 16 14:00:02 1998
To: Matt Curtin <cmcurtin@interhack.net>
cc: perry@piermont.com, Phil Karn <karn@qualcomm.com>, cryptography@c2.net
Date: Thu, 15 Oct 1998 22:53:47 -0400
From: "Steven M. Bellovin" <smb@research.att.com>
In message <864st6auew.fsf@strangepork.interhack.net>, Matt Curtin writes:
>"Perry E. Metzger" <perry@piermont.com> writes:
>
>> In the long run, though, the only solid solution is using a superior
>> language, like Java, for tasks that aren't extremely time critical.
>
>One of the things that I've noticed about code that is error prone
>comes from inexpert use of the language in question. While lower
>level languages like C and assembly make it easy to introduce security
>(and other) bugs, these are typically in ways that are unrelated to
>the software being developed. Blown buffers, memory management
>problems, etc.
Right. But saying "correct coding will not encounter the problem" doesn't scale.
We need new tools -- languages, paradigms, operating system primitives, and
the like -- to help the average programmer.
As always, complexity is the enemy. That might, in fact, be the problem with
Ada -- anyone who remembers the process that led to its adoption will remember
the vitriolic complaints about its complexity, and what that implied for the
correctness of software written in it. Features interact to produce errors.
Nor am I prepared to say that these are only "harmless" errors from a security
perspective. Nor -- since I don't know Ada -- do I know if it subsets cleanly.
(Languages may not. Those of you who know PL/1 well will remember the horrors
of fixed point division because of the precision rules. Those of you who don't
know it are lucky...)
That said, I'm prepared to cut a lot of slack for languages or implementations
thereof that solve the buffer overflow problem, simply because it has become such
a pervasive threat. (Yes, even PL/1...)
I'm also interested in languages with built-in security properties. That's
one of the attractions of Java: a program that is intended to access just
a small subset of possible filenames can use the Java security manager class --
the same one intended to confine applets -- to help protect against trickery
by users of the program. That is, instead of using the security manager to
protect me against folks who send me hostile Java code, I want to use it to
protect my own code against people who send my programs hostile input. I don't
think it's a panacea, and it's certainly possible (probable?) that the security
manager classes aren't correct, either -- but it's another layer of defense.
Since this is a cryptography list, I should note that crypto software is
also susceptible to bugs. Even apart from protocol design issues -- a separate
can of worms -- crypto software is still software, and heir to all of its ills.
There isn't that much crypto stuff out there; I wonder if the number of CERT
advisories on it is in fact out of proportion to its use. (My favorite non-protocol
crypto bug was the Kerberized telnet, where -- due to an interface mismatch
between assorted other pieces and the DES library -- there was a 255/256 probability
that the stream would be encrypted with a constant key. But it always looked
encrypted!)
