Cobol is highly structured and very difficult to just whip together a program. Your DATA section had to be specified EXACTLY as your design specifies. Any program which input data over the stated limit would give an exception. On the older mainframes your program would terminate. Do not have any experience with later mainframes. The whole operating environment for a mainframe is a charge based model with extensive resource control which, as a side effects, provides stronger program execution security. You can limit I/O access with a mainframe which is very difficult with our new generation of operating systems. Have not done anything with Cobol since the mid 80's. There are probably many variations since then which allow 'features' to extend its life and possibly loosen its strict structure. Using it on a Univac and Honeywell systems in batch mode your program had to be EXACT or the mainframe would not compile it. Paul Powenski
ljknews <[EMAIL PROTECTED]> wrote: At 9:16 PM +0100 11/1/07, Johan Peeters wrote: > I think this could do a great service to the community. > > Recently I was hired by a major financial institution as a lead > developer. They said they needed me for some Java applications, but it > turns out that the majority of code is in COBOL. As I have never > before been anywhere near COBOL, this comes as a culture shock. I was > surprised at the paucity of readily available information on COBOL > vulnerabilities, yet my gut feeling is that there are plenty of > security problems lurking there. Since so much of the financial > services industry is powered by COBOL, I would have thought that > someone would have done a thorough study of COBOL's security posture. > I certainly have not found one. Anyone else? Can anyone point to stories about Cobol exploits ? I mean exploits that have to do with the nature of the language, not social engineering attacks that happened to take place against a Cobol shop. My limited exposure to Cobol makes me think it is as unlikely to have a buffer overflow as PL/I or Ada. -- Larry Kilgallen _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
