Re: [SC-L] Programming languages -- the third rail of secure coding
Jeremy Epstein wrote: Kevin Wall pointed to http://www2.latech.edu/~acm/HelloWorld.shtml as a good source point; several of the languages I programmed in aren't listed (e.g., PL/360, which in many respects was to the IBM 360 as C was to the PDP/11). Throughout the 1970s (and maybe even 1980s) a researcher named Jean Sammet at IBM published a yearly list of what claimed to be all the programming languages in use. See http://www.computerhistory.org/events/hall_of_fellows/sammet/ for more about her. To relate this to security, I discovered the concept of a buffer overrun when writing PL/360 code back in 1978. Languages that lack strong typing, like PL/360 and C, clearly have a harder time being secure than those that aren't. And that's true of reliability as well. So perhaps such a list would be interesting if one identified the characteristics that make a language good from a security perspective (several such lists have been posted to this list), and then correlate it to some of the very long lists of languages. That would at least give a starting point for a discussion of best IMHO, though, any such effort is pointless. The reality is that we're going to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various interpreted/scripting languages for a very long time. Rather than argue about what makes something good/better, we'd be better off figuring out how to use them more effectively. As engineers, we need good enough, not perfection. Perhaps this term engineer will cause mischief though. A civil engineer (you know...one of those guys who takes the PE exam...) designs things according to principles. They also get licensed once they convince examiners they can design to correct mechanical engineering principles. However nothing they do is designed to combat malicious attack. Someone takes a field piece and blows the supports of a building to Kingdom come, and the building engineer is NOT at fault. There is a craft of fortress design. Like some software design now, it builds up knowledge and has preferred practices, but rests on being able to invent defenses to whatever attacks people dream up. While a fortress designer should of course know what other fortress designers are up to, his success will be also determined by how inventively and effectively he can counter new threats. This is not something that exams are very effective at. It is also something that is very close to much of software work these days. I recall when a buffer overflow would have been looked at in terms of some random line noise or error sending too much garbage down a line. Result usually would be a crash, and possibly restarted app seconds later, and it is entirely possible it might be no big deal. The problem is we are not dealing with a civil engineering type of environment where random accidents are the threat. The threats are humans who carefully design new threats. And we must be thinking of how to counter them. Unlike the building design case, too, it's hard to know when you're done when designing fortifications. (Consider how long the best Roman fortress in the world would stand up to a 21st century armed force; yet some of those forts were quite good when new.) I don't see that something like engineering necessarily can be applied to security design. At any rate it could be useful to the uninformed not to lose sight of the craftsmanship that is daily work. Glenn Everhart
RE: [SC-L] Programming languages -- the third rail of secure coding
At 1:03 PM +0930 8/1/04, Nick Lothian wrote: IMHO, though, any such effort is pointless. The reality is that we're going to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various interpreted/scripting languages for a very long time. What are peoples opinions of the languages listed above? Would I be overly controversial in saying: C/C++: Unsafe (for most people) It is possible to code correctly in (almost) any language, but the likelihood of success varies. To me the big issue of C* languages has to do with what assurances _management_ has that the effort will result in correct code. The C++ compilers I know of allow a programmer to drop into raw C, and given the low level of understanding safety and security issues across the programming population there will be a strong temptation to do that. Java/C#: Reasonably safe (both provide protection against buffer overflows, are type safe and provide built-in security mechanisms) FORTRAN/COBOL: Don't know - my impression is that COBOL is fairly safe Scripting Languages: Depends on the language. Lack of type safety can be a problem, but on the other hand they are usually safe from buffer overflows and the fact they you can do a lot more in fewer lines of code can make the code safer by making errors more obvious. Are there other languages in widespread use (ie, the language must be used more than - say - Python) that are safer than those listed above? Certainly Ada is a lot safer than those above, and the SPARK subset we have discussed here is even safer (not just by being a subset but also by supporting proofs of correctness). SPARK is much less widely deployed that whatever was used to implement Internet Explorer, but I have strong preference as to which of the two I would want used in the programming of fly-by-wire for an airplane on which I fly. -- Larry Kilgallen
RE: [SC-L] Programming languages -- the third rail of secure
IMHO, though, any such effort is pointless. The reality is that we're going to be stuck with C/C++, Java, C#, FORTRAN, COBOL, and various interpreted/scripting languages for a very long time. Rather than argue about what makes something good/better, we'd be better off figuring out how to use them more effectively. The problem is that some people persist in using less-safe languages for new code. When put into a discussion (here) with those who say Use the best tool, a non-conversation takes place. If the list were retitled to be Secure Coding in Unsupportive Languages or Secure Coding with Approprate Languages then half of us would leave and the rest could actually conduct a discussion. -- Larry Kilgallen What are peoples opinions of the languages listed above? Would I be overly controversial in saying: C/C++: Unsafe (for most people) Java/C#: Reasonably safe (both provide protection against buffer overflows, are type safe and provide built-in security mechanisms) FORTRAN/COBOL: Don't know - my impression is that COBOL is fairly safe Scripting Languages: Depends on the language. Lack of type safety can be a problem, but on the other hand they are usually safe from buffer overflows and the fact they you can do a lot more in fewer lines of code can make the code safer by making errors more obvious. Are there other languages in widespread use (ie, the language must be used more than - say - Python) that are safer than those listed above? Nick
