Mainframe Security

[yo at secappdev.org (Johan Peeters)]

I have been looking at an IBM system. If I do something like this

          ...
           01 txt                             PIC  X(120)
           ....
           string '**'
             into txt
           end-string
           display txt

I get to see ** on sysout followed by what appears to be selected
contents of the data section. This strikes me as somewhat worrysome -
it reminds me of the format string vulnerabilities in C.
Am I just being paranoid?

kr,

Yo

On 11/2/07, Paul Powenski <ppowenski at yahoo.com> wrote:
> 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 <ljknews at mac.com> 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 at 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 at 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.
> _______________________________________________


-- 
Johan Peeters
http://johanpeeters.com