Clearly, programming languages were intended to convey programmer intent to
a computer.  They were not designed to solve security issues.  Those issues
mostly exist at a higher level of abstraction than bit fiddling, where
programming languages excel.  This is to say that programming languages are
able to help automatically to implement certain aspects of security.  We
have already seen, for example, Microsoft deploy managed code that does not
permit the computer to overflow buffer boundaries.  Further, it does not
permit collection elements to be coerced away from their natural types.
There are no pointers hence there is no pointer arithmetic.  Similar
mechanisms exist in J2EE.  These are delightful.  I long ago asked to have
these capabilities provided, only to be told that performance was king and
no way would compiler writers add to path length (i.e. degrade performance)
to halt the program should such untoward events occur.  But, let's not get
carried away.  These things that compilers can do for us do not cover a vast
range of security issues such as closing off IP ports to any but
authenticated users and coding carefully to guarantee illicit user input
does not slide by unchallenged as a database command.

Empirically, it does seem that a whole class of security-related errors in
Microsoft software could be wiped away by porting the code to the managed
arena.  It has been simply too easy to write code that works correctly
except in the case of unanticipated (e.g. nonconformant) input.

Mark Rockman
----- Original Message ----- 
From: "Michael S Hines" <[EMAIL PROTECTED]>
Sent: Thursday, July 22, 2004 10:32
Subject: RE: [SC-L] Programming languages -- the "third rail" of secure

> Concur this is a 'rabbit trail' not worth pursuing.
> For those who assisted with the list, thank you.
> Otherwise, I suggest we return to our regularly scheduled program at this
> time.
> Mike Hines
> -----------------------------------
> Michael S Hines

Reply via email to