RE: [SC-L] Programming languages -- the third rail of secure coding
At 2:25 PM +0930 8/2/04, Nick Lothian wrote: What features make Ada safer than Java/C#? (I only have limited experience with Ada but from memory there was nothing that jumps out at me as something that Java lacks) Quoting from Tucker Taft in http://www.google.com/groups?selm=FD85Lq.Hyp.0.-s%40inmet.camb.inmet.com Integer conversion (casting) in Java is truncating. Integer conversion in Ada is value-preserving, with a run-time check on overflow (note that GNAT in some configurations suppresses overflow checks by default, which is naughty in some people's view ;-). To get truncation in Ada, you need to use an explicit mod/rem or Unchecked_Conversion. Markus Kuhn has a general comparison between Ada, Java and C++ at http://www.google.com/groups?selm=77nhuv%2429c%243%40pegasus.csx.cam.ac.uk Real-time aspects of Java garbage collection are discussed at http://www.google.com/groups?selm=a3eaa964.0304162240.540962aa%40posting.google.com Enumerated types are discussed at http://www.google.com/groups?selm=sbrvtvgdcdjps866mbuonffsl816ucgipd%404ax.com Comparing the Ada protected object to the Java monitor http://www.google.com/groups?selm=82347202.0305061140.53347ae1%40posting.google.com and other synchronization issues http://www.google.com/groups?selm=3D0CA980.5050505%40worldnet.att.net Strong typing of scalars http://www.google.com/groups?selm=254c16a.0305190830.21c61eca%40posting.google.com Lack of generics means containers are not type-safe in Java http://www.google.com/groups?selm=ba162549.0301052052.5a03f7a7%40posting.google.com Reference to a general comparison document from ACT Europe http://www.google.com/groups?selm=W0er9.42832%24qb.14876%40nwrddc01.gnilink.net -- Larry Kilgallen
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 coding
I'd also point out that if it's languages you're trying to list, JavaScript arguably should not have a separate entry from Java Yes it should - they are substantially different languages, even if we look at them only syntactically. You could argue that Javascript should be listed as ECMAScript, though. There are a bigger problems with that list than this, though. Nick
Re: [SC-L] Programming languages -- the third rail of secure coding
JOVIAL goes back to the 1960s as Jules' Own Version of the International Algebraic Language. ALGOL and IAL are the same thing. JOVIAL was used almost exclusively by the United States Air Force. - Original Message - From: Dave Aronson [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 11:05 Subject: Re: [SC-L] Programming languages -- the third rail of secure coding Michael S Hines [EMAIL PROTECTED] wrote: I've been compiling a list of programming languages.. You missed FORTRAN, ICON, REXX, SNOBOL, and the assorted OS-based shell scripting languages (bash/csh/ksh/etc., VMS DCL, DOS .bat, etc.). I've heard of JOVIAL, which I *think* is a programming language used almost exclusively in the US military. Since a few companies make things that translate it into code, you might consider UML as well. Then there are a gazillion languages for particular commercial packages -- you got Oracle's PL/SQL, but there are also dBase/Clipper, FrEd (Framework Editor, from an old integrated office suite), Lotus 1-2-3 macros, and many more. Also, depending on your definition of programming language (versus markup language and a few other types), you might have a few extras as well. -- David J. Aronson, Contract Software Engineer in Washington DC area Resume and other information online at: http://destined.to/program
Re: [SC-L] Programming languages -- the third rail of secure coding
At 8:17 AM -0500 7/20/04, Michael S Hines wrote: I've been compiling a list of programming languages.. Some of which were developed to 'solve' the insecure programming problem. I don't think we've made it yet. My list -- (feel free to add to it). And then there are languages such as Java2K that were never intended to *solve* any problems at all ... http://p-nand-q.com/humor/programming_languages/java2k/manual.html --erik
Re: [SC-L] Programming languages -- the third rail of secure coding
I don't understand the purpose of this list. If it is to list all programming languages, that is hopeless, as there are thousands of programming languages. If it is to list all programming languages with security ambitions, then I'm confused, as clearly not all of the languages listed were intended to enhance security, and some of them (glaringly PHP) substantially *degrade* security vs. many languages that came before them. Crispin Michael S Hines wrote: I've been compiling a list of programming languages.. Some of which were developed to 'solve' the insecure programming problem. I don't think we've made it yet. Perhaps it's a personnel problem, not a technology problem? My list -- (feel free to add to it). 1. Assembler 2. C/C++ 3. Pascal 4. Basic or Visual Basic 5. Java / J# 6. Perl 7. Ruby 8. PHP 9. C# 10. COBOL 11. Perl 12. XSLT 13. Python 14. Forth 15. APL 16. Smalltalk 17. Eiffel 18. PL/1 19. ADA 20. Hermes 21. Scheme 22. ML 23. Haskell 24. Simula 67 25. Prolog 26. OCCAM 27. Modula 2 28. PL/M or PL/X 29. PL/SQL 30. SQL 31. Jabber 32. Expect 33. Perl/Tk 34. Tcl/Tk 35. XML 36. HTML 37. AppleScript 38. JavaScript 39. VBScript 40. D 41. Algol --- Michael S Hines [EMAIL PROTECTED] -- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
Re: [SC-L] Programming languages -- the third rail of secure coding
Michael S Hines [EMAIL PROTECTED] wrote: I've been compiling a list of programming languages.. You missed FORTRAN, ICON, REXX, SNOBOL, and the assorted OS-based shell scripting languages (bash/csh/ksh/etc., VMS DCL, DOS .bat, etc.). I've heard of JOVIAL, which I *think* is a programming language used almost exclusively in the US military. Since a few companies make things that translate it into code, you might consider UML as well. Then there are a gazillion languages for particular commercial packages -- you got Oracle's PL/SQL, but there are also dBase/Clipper, FrEd (Framework Editor, from an old integrated office suite), Lotus 1-2-3 macros, and many more. Also, depending on your definition of programming language (versus markup language and a few other types), you might have a few extras as well. -- David J. Aronson, Contract Software Engineer in Washington DC area Resume and other information online at: http://destined.to/program
Re: [SC-L] Programming languages -- the third rail of secure coding
I've been compiling a list of programming languages.. [...] My list -- (feel free to add to it). 42. BCPL 43. sh 43. awk 44. FORTRAN 45. TeX 46. Metafont 47. PostScript 48. MUF 49. BLISS 50. Machine code I'd also point out that if it's languages you're trying to list, JavaScript arguably should not have a separate entry from Java (and probably VBScript vs Visual Basic too). I also think ADA should be spelled Ada - you seem to be _trying_ to capitalize correctly /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
