ljknews 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. I recall that in the past some third party packages have had inadequate checking of system call parameters and opened holes in mainframe security. Supposedly the one I heard about got fixed eventually. Don't recall hearing about anything with COBOL though. It is not stack oriented, doesn't tend to use pointers like C does - more like subscripts or record numbers - so the kinds of things you might get could be more like array bounds being exceeded if the compiler is not checking for this, or if you are using binary format integers you might be able to produce integer overflow here and there. That too tends to have code to check it built in. COBOL and other old languages tend to have a lot of healthy habits derived from having to work at all in tiny environments - production machines with 8196 bytes of memory and the like. Also remember OS/360 and following use record oriented I/O - open a file and you can specify it has 80 byte records, and a read operation will return 80 bytes. None of this fiddling with null terminators or being able to insert newlines; they are just characters. In such environments you get used to doing I/O as records, with size information carried around everywhere. Makes many kinds of mischief hard to get away with.
I would in such a system look for holes rather in the bits of Java or C that might be in there as late additions where this discipline has not been a part of its history. I believe there are some old COBOL static analyzers around, but also expect most of the compilers these days on mainframe probably can insert code to check for most of the overflow conditions mentioned with a compiler switch, so that having such checking is at least a common development practice. Glenn Everhart _______________________________________________ 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. _______________________________________________