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 MDRSESCO LLC ----- Original Message ----- From: "Michael S Hines" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 22, 2004 10:32 Subject: RE: [SC-L] Programming languages -- the "third rail" of secure coding > 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 > [EMAIL PROTECTED] > >
