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
> >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 > 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) Nick
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
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
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] > >
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]
Re: [SC-L] Programming languages -- the "third rail" of secure coding
At 1:22 AM -0700 7/21/04, Crispin Cowan wrote: 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. The list would make more sense if the languages were classified by type, e.g. imperative, functional, logic, declarative, etc. (Or some other set of classifications/labels around which a consensus can be found.) Then a question arises, is there any particular class of language that lends itself better to secure programming than the others? Craig -- Internet: [EMAIL PROTECTED]
Re: [SC-L] Programming languages -- the "third rail" of secure coding
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. If you want a list of all programming languages (or at least around 2500 of them), try this page: http://people.ku.edu/~nkinners/LangList/Extras/langlist.htm The computer languages history page at http://www.levenez.com/lang/ is a good reference for this type of information too, and O'Reilly has put out a family tree poster(http://www.oreilly.com/news/graphics/prog_lang_poster.pdf) of a couple hundred of the more important or commonly used languages. [Ed. Ok, lists are great, but could we please either kill this thread or reel it in and focus on the security strengths/weaknesses of the various languages? Thanks! KRvW] -- James Walden, Ph.D. Visiting Assistant Professor of EECS The University of Toledo @ LCCC http://www.eecs.utoledo.edu/~jwalden/
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
> 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
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
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Michael S Hines > Sent: 20 July 2004 14:17 > To: [EMAIL PROTECTED] > Subject: RE: [SC-L] Programming languages -- the "third rail" > of secure > coding > > > 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? > True. Except that a major part of the "personnel problem" is the refusal of the personnel to be open minded and objective about their choice of technology! Peter ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. The IT Department at Praxis Critical Systems can be contacted at [EMAIL PROTECTED] This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
RE: [SC-L] Programming languages -- the "third rail" of secure coding
der Mouse wrote... [Michael Hines wrote] >> I've been compiling a list of programming languages.. [...] >> My list -- (feel free to add to it). > > 42. BCPL > 43. sh [snip] > 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 I already responded off-list to Michael Hines, the originator of this thread, but perhaps I can just add if all everyone is interested in is a list of programming languages, you can find a nice list at the ACM Hello World page: http://www2.latech.edu/~acm/HelloWorld.shtml I would have mentioned it earlier had I known that we were going to continue down this rabbit trail. Besides, there are lots of other similar sites available. (Google is your friend. ;-) Now let's get back on track of WHAT collecting such a list has to do with secure programming. Does the original poster (Michael Hines) intend on developing an ontology of programming languages based on how they support (or fail to support--whoa, really big list ;-) secure programming? If so, I can see how we might all learn some lessons from that. If not, I guess I'm missing the whole point this thread was started, so please enlighten me. Thanks, -kevin wall --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED]Phone: 614.215.4788 "The difference between common-sense and paranoia is that common-sense is thinking everyone is out to get you. That's normal -- they are. Paranoia is thinking that they're conspiring."-- J. Kegler
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
> 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
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. > >Perhaps it's a personnel problem, not a technology problem? > >My list -- (feel free to add to it). > >1. Assembler >19. ADA The proper capitalization is Ada. Unlike Cobol and Fortran it never was defined as all caps. >41. Algol 42. Bliss -- Larry Kilgallen
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.. 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]
