Re: Public disclosure of discovered vulnerabilities

From: John A. Malley (102667.2235_at_compuserve.com)
Date: 06/08/05 

Date: Wed, 08 Jun 2005 05:55:25 GMT

David Wagner wrote:
> Hank Oredson wrote:
>
>>"David Wagner" <daw@taverner.cs.berkeley.edu> wrote:
>>
>>>What this means: To program securely in C, you have to know the intricate
>>>details of the C Standard in all its glory. Compare, for instance, to
>>>Java -- programming securely in Java does not seem to require the same
>>>level of intimacy with the official Java language specification document.
>>
>>Just the same for PL/I, FORT|RAN, your VCR, your automobile ...
>
>
> Strawmen, all of them. I spoke of Java; I notice it is conspicuously
> absent from your list. Is that because you are not familiar with modern
> languages like Java? Or is that because you agree that modern languages
> like Java are different?
>
> I don't know about PL/I or FORTRAN, but my opinion is that Java does
> not go on this list. You don't have to have memorized the Java and
> JVML official specifications to use Java securely. In C, you do. In
> C, it is not enough to learn from a textbook or reference book: you have
> to actually read the entire C Standard itself and memorize all its little
> corner cases, if you want to program securely. That's generally not
> necessary when programming in Java.
>
> (By the way, Java is just an example -- I suspect many other modern
> languages are much like Java in this regard.)
>
> An additional comment: What you say is not true of a VCR or an automobile.
> I don't have to read the technical specs and the blueprints of a VCR to
> know how to use it. The technical specs & blueprints are only needed by
> those who construct or repair VCRs. Now let's compare to C: in C, it's
> not just the compiler writers who have to memorize the whole C Standard --
> it is every single programmer who wants to use the language securely.

Wow, this is what we call the "mental model" problem in aerospace. I can see the
same phenomenon here with the choice of programming language for a
Internet-connected application.

People (programmers, pilots) interact with a complex system (a programming
language and its compiler, a large commercial transport airplane) to accomplish
some task (instantiating beneficial functionality in the form of an app that
runs on a machine, moving people from point A to point B through controlled
airspace.)

These people keep a "mental model" of the complex system in their heads while
interacting with the system (programming language and compiler, airplane.) This
mental model is a cognitive aid for planning and predicting system responses to
user inputs, and for understanding system responses in the presence of errors or
malfunctions. The less accurate the mental model, the more severe and probable
the human errors when dealing with the complex system. There are several
spectacular and tragic airplane accidents in the past 1 -2 decades directly
attributed to "pilot error," but the errors made resulted from the gross
mismatch between the crews' mental model of the automated systems on board the
airplane (autopilots, autothrottle, flight management system, air data computer,
interactions between electrical and hydraulic systems supporting the same) and
the actual "rules of behavior" for these complex systems when something fails in
one area and cascades or changes behavior in other areas.

I think there's a direct relationship between the programmer/software engineer's
"mental model" of the programming language verses security errors when
implementing an Internet-aware application in that language.

Now I'm not a C programmer by a long shot, but reading this thread these past
few days, and its ancestral thread a month of so back, we see examples of C
language behavior with respect to unintended consequences like buffer overruns
that are not immediately clear to sci.crypt regulars who use C a lot. They have
a mental model of the language, and expectations as to what should happen in
certain situations, and it appears that C occasionally throws the most
experienced a curve ball.

The mental model required to ensure secure coding when using C is rigorous and
demanding, as you said,

> In C, it is not enough to learn from a textbook or reference book: you have
> to actually read the entire C Standard itself and memorize all its little
> corner cases, if you want to program securely.

Those corner cases mean one needs a more extensive and unforgiving "mental
model" of the language, and woe to those using a "naive" C mental model in ways
novel to the programmer.

Some posters in comp.arch (I surmise you are regulars there since I don't see
your names often in sci.crypt) have very accurate "mental models" of C, as I
would venture Doug Gwyn from sci.crypt does as well. But that model requires a
lot of time and effort to build.

Strong typing and automated bounds checking in Java allows for a closer match
between the "typical" programmer's mental model of the Java code (what it will
do in response to yada yada yada) and the actual response of the code with
respect to secure coding. It's more forgiving of a mismatch between the naive
programmer's mental model for the language and the actual characteristics and
defined behaviors of Java byte code.

Well, that's my hypothesis, it's not a fact.

It might make a great study - correlation between the kinds of secure coding
errors made when using a language, and the language characteristics that promote
security in the face of programmer's "mental model" errors.

(This approach is now taken in aerospace, there's a lot of research into human
factors and cognitive aids to prevent "mode confusion" and to promote a better
pilot "mental model" of the true state of automated systems on the airplane, and
what will happen in the face of certain supporting system malfunctions.
Commercial transport designs got rid of the flight engineer in the 1980s, that
one person who knew every system in the airplane inside and out. Pilots flew as
flight engineers before they flew as pilots, and thus learned a great deal about
the corner conditions and interactions of myriad supporting systems on the
airplane type.)

John A. Malley
102667.2235@compuserve.com

Quantcast