Mainframe Security

[everhart at gce.com (Glenn and Mary Everhart)]

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