[SC-L] COBOL Exploits

2007-11-02 Thread Mark Rockman
The adolescent minds that engage in exploits wouldn't know COBOL if a printout fell out a window and onto their heads. I'm sure you can write COBOL programs that crash, but it must be hard to make them take control of the operating system. COBOL programs are heavy into unit record equipment

Re: [SC-L] Mainframe Security

2007-11-02 Thread Paul Powenski
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

Re: [SC-L] COBOL Exploits

2007-11-02 Thread security curmudgeon
Hi Mark, : The adolescent minds that engage in exploits wouldn't know COBOL if a : printout fell out a window and onto their heads. I'm sure you can write : COBOL programs that crash, but it must be hard to make them take control : of the operating system. COBOL programs are heavy into unit

Re: [SC-L] COBOL Exploits

2007-11-02 Thread ljknews
At 12:13 AM -0400 11/2/07, Mark Rockman wrote: The adolescent minds that engage in exploits wouldn't know COBOL if a printout fell out a window and onto their heads. I'm sure you can write COBOL programs that crash, but it must be hard to make them take control of the operating system. Of

Re: [SC-L] Mainframe Security

2007-11-02 Thread ljknews
At 4:11 PM +0100 11/2/07, Johan Peeters wrote: Let me offer a little variant on the previous theme though to illustrate, hopefully more convincingly, why I find COBOL worrisome: ... 01 txtpic x(2). move 'hi' to txt call

Re: [SC-L] Mainframe Security

2007-11-02 Thread 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

Re: [SC-L] Mainframe Security

2007-11-02 Thread 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

Re: [SC-L] Mainframe Security

2007-11-02 Thread ljknews
At 2:16 PM +0100 11/2/07, Johan Peeters wrote: 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

Re: [SC-L] Mainframe Security

2007-11-02 Thread Gergely Buday
On 02/11/2007, Glenn and Mary Everhart [EMAIL PROTECTED] wrote: I believe there are some old COBOL static analyzers around, One of them is the Anno Domini system, which was developed to help the Y2K (do anybody remember what was this hype?) experts to do their work.

Re: [SC-L] COBOL Exploits

2007-11-02 Thread Peter G. Neumann
Searching through http://www.csl.sri.com/neumann/illustrative.html gives these COBOL-related RISKS items. The initial character descriptors are defined there. In the citations, * R relates to RISKS (archives at risks.org) * S relates to SIGSOFT Software Engineering Notes (archives at

Re: [SC-L] Mainframe Security

2007-11-02 Thread Florian Weimer
My limited exposure to Cobol makes me think it is as unlikely to have a buffer overflow as PL/I or Ada. Usually, Ada programmers switch off bounds checking before shipping code. I don't know why Ada has such a reputation for robustness. ___ Secure

Re: [SC-L] Mainframe Security

2007-11-02 Thread ljknews
At 11:45 PM +0100 11/2/07, Florian Weimer wrote: My limited exposure to Cobol makes me think it is as unlikely to have a buffer overflow as PL/I or Ada. Usually, Ada programmers switch off bounds checking before shipping code. I don't know why Ada has such a reputation for robustness. Can