[email protected] (Martin Packer) writes: > If I remember rightly Pascal does bounds checking. Pascal was one of the > languages I did at college - and the highest-level one. A bit of a shock > to me to discover - in an IBM Systems Engineer training homework > assignment - that COBOL didn't. (This was in 1986.) The result was me > stomping over the code by assigning values to array elements using only > slightly excessive subscript values. :-) I think I learnt something from > that. :-) > > I mention this because the bounds checking in Pascal is probably what > prevented buffer overrun issues (and nowadays with C etc actual exploits).
re: http://www.garlic.com/~lynn/2013.html#27 Java Security http://www.garlic.com/~lynn/2013.html#28 Java Security student versions of fortran, pascal, pli, etc tended to do a lot more checking that production versions. pascal & pli have much better (length related) storage, buffer, & array paradigm than c-language. part of the issue is that c-language has convetion of implicit lengths with null terminator ... while other languages have had convention of explicit lengths. the null terminator & implicit length paradigm contributes significantly to a huge increase in programming errors (there have been long drawn out discussions about expert programmers are subject to such errors ... but the analogy has been used with auto & highway safety engineering ... countermeasures for the most common types of failings). note there was ibm review of the air force security audit of multics (some number of the mit 7094/ctss people went to 5th flr to do multics and other went to the ibm science center on 4th flr and did virtual machines, internal network and bunch of other things). One of the ibm references was that multics (implemented in pli) also didn't have any buffer length related exploits. old reference http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation the paper was originally at: domino.watson.ibm.com/library/cyberdig.nsf/papers/FDEFBEBC9DD3E35485256C2C004B0F0D/$File/RC22534.pdf but now found at http://www.acsac.org/2002/papers/classic-multics.pdf note I had done a mainframe "dump reader" ... for some reason it was never shipped ... but at one time it was in used at majority of the internal datacenters and a huge percentage of all (customer support) PSRs. Part of the effort I did study of most common mainframe failures and then did library of code for the dump reader that automatically checked for large percentage of identifiable failure signatures. One of the most common system failures were dangling pointers ... i.e. asynchronous activity where a pointer was being used after the storage area had been released for other pointers. One of the benefits claimed for JAVA ... was automagically handling the dangling pointer failure mode. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
