[3502] in cryptography@c2.net mail archive
Re: Medium-term real fix for buffer overruns
daemon@ATHENA.MIT.EDU (Markus Kuhn)
Fri Oct 16 18:41:15 1998
To: karn@qualcomm.com
cc: cmcurtin@interhack.net, perry@piermont.com, cryptography@c2.net
In-reply-to: Your message of "Thu, 15 Oct 1998 17:08:34 PDT."
<m0zTxRa-0014d7C@laptop.ka9q.ampr.org>
Date: Fri, 16 Oct 1998 22:37:12 +0100
From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>
Phil Karn wrote on 1998-10-16 00:08 UTC:
> >screw up our algorithms, our protocols, and whatnot. We're still
> >going to have to be careful and inspect each others' work.
>
> This is key. No matter how good our languages get, programmers will
> still make mistakes. Languages may help prevent stupid, low-level bugs
> like buffer overruns, but there will always be bugs too subtle or
> complex for a machine to find automatically.
>
> The single most effective mechanism we've found so far for correcting
> these mistakes is open publication and peer review -- the scientific
> method in action.
Agreed. And this is still very much a language issue: C and even more so
C++ is a language that makes thorough reviews by others extremely
difficult! A language like Ada supports external code reviews extremely
well by enforcing a large number of safety properties onto the code that
C reviewers tediously have to check manually instead of being able to
rely on the guarantees of the compiler.
Especially the lack of arrays in C is particularly disastrous here,
because since the C compiler cannot guarantee that its pseudo-array
write accesses really reach the intended data object. C, like assembler,
makes effects of many errors completely non-local. A piece of code that
you inspect can behave completely differently if by accident or malice
other code messed up your data structure.
But the lack of arrays are not the only weakness of C. Many other
features in Ada are also intended to make it more difficult for
accidental or intentional bugs to escape the reviewer's eye. This starts
with trivial features such as for-loop variables being constants inside
the loop, which guaranteeing that the expressions in the loop header are
the only determining factors for how often the loop executes. And this
continues with proper mechanisms such as packages, which guarantee a
clear restriction of the scope of objects to their respective modules,
and other mechanisms for the design of proper and robust intra-module
interfaces in large applications.
Markus
--
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>
