Secure Coding mailing list archives
Re: Programming languages -- the "third rail" of secure coding
From: "Mark Rockman" <mrockman () acm org>
Date: Fri, 23 Jul 2004 14:36:40 +0100
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]
Current thread:
- RE: Programming languages -- the "third rail" of secure coding, (continued)
- RE: Programming languages -- the "third rail" of secure coding ljknews (Jul 20)
- Re: Programming languages -- the "third rail" of secure coding Erik van Konijnenburg (Jul 21)
- Re: Programming languages -- the "third rail" of secure coding der Mouse (Jul 20)
- Re: Programming languages -- the "third rail" of secure coding Crispin Cowan (Jul 21)
- Re: Programming languages -- the "third rail" of secure coding Craig E. Ward (Jul 22)
- Re: Programming languages -- the "third rail" of secure coding James Walden (Jul 21)
- RE: Programming languages -- the "third rail" of secure coding ljknews (Jul 20)
- RE: Programming languages -- the "third rail" of secure coding Peter Amey (Jul 21)
- RE: Programming languages -- the "third rail" of secure coding Wall, Kevin (Jul 21)
- RE: Programming languages -- the "third rail" of secure coding Nick Lothian (Jul 21)
- RE: Programming languages -- the "third rail" of secure coding Michael S Hines (Jul 22)
- Re: Programming languages -- the "third rail" of secure coding Mark Rockman (Jul 23)
- RE: Programming languages -- the "third rail" of secure coding Nick Lothian (Aug 02)
- RE: Programming languages -- the "third rail" of secure coding ljknews (Aug 02)