Re: [SC-L] Mainframe Security
In my experience of reviewing COBOL and mainframes in general, it's worthwhile to evaluate doing bad things to the business logic. The designers are literal in their translation of the business requirements to specifications, and never think of the mis-use cases. Mainframe coders aren't paid to design and implementing missing links in the design, and are often penalized if they stray too far from the specification. Therefore, as Peter pointed out in a previous thread, almost all of the "exploits" for mainframes goes after the golden apples - the business logic and the underlying asset. Luckily, up until recently, data which violated the requirements wasn't easy to get in, but now it's more than easy: a) a system I am aware of used to be green screen only and had validation to prevent unauthorized characters like commas in the presentation layer. Once the underlying transaction was made available to process transactions from the Internet, customers finally could manipulate this data. Someone didn't bother to eliminate "," as a valid character as it wasn't in the spec - they only had a few characters to eliminate and "," wasn't one of them. The comma upset the strip (batch data) file. Caused several abends and a lot of sleepless nights for the folks whilst they worked out how to get rid of this troublesome character from a multi-gigabyte file and successfully re-run the batch without re-processing already processed transactions. b) I have spaces in my name. Galileo, the online booking system used by pretty much everyone is written on top of TPS, an old (and I mean OLD - it's older than me) OS for IBM mainframes. TPS is written in assembly language, as is most of the Galileo transactions for freight and self-loading freight (humans). If you try like me to enter the legally required spaces in your name as often as you can, it's nearly funny the number of times I've had to get manual assistance to get on planes and through the TSA checkpoint. I'm sure it's because Galileo doesn't handle spaces properly. I wonder what other characters it doesn't like. c) The EOF marker in EBCDIC works real well. If your outside program can send it in a field and it doesn't mean anything to anyone ... until it hits a file, you can cause a lot of problems, particularly with batch driven systems. Luckily, most front end systems I come across don't know what to do with low ASCII entries and either don't pass it on, or fail to translate it properly, thus preventing a workable attack. thanks, Andrew smime.p7s Description: S/MIME cryptographic signature ___ 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. ___
Re: [SC-L] Mainframe Security
> 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 you provide a pointer to the study showing that ? A lot of programmers used to follow the example of GNAT's run-time library, which is compiled with -gnatp, turning off bounds checks (among others). There's also a certain influence from the certification crowd who detests dead code. But it seems that there's been a move away from -gnatp during the last couple of years. I hadn't noticed this. Thanks. ___ 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. ___
Re: [SC-L] Mainframe Security
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 you provide a pointer to the study showing that ? Certainly none of the Ada I ship has bounds checking disabled. -- 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. ___
Re: [SC-L] Mainframe Security
> 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 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. ___
Re: [SC-L] Mainframe Security
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. http://portal.acm.org/citation.cfm?id=292543&dl=ACM&coll=portal - Gergely Buday ___ 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. ___
Re: [SC-L] Mainframe Security
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 'evil-code' using txt > > > IDENTIFICATION DIVISION. >PROGRAM-ID. evil-code. >DATA DIVISION. >linkage section. >01 assetPIC X(1200). >procedure division using asset > > > The author of evil-code now has a selection of the contents of the > caller's data segment at his disposal. Are you saying that evil-code is written in some language that allows it to take advantage of by-reference semantics to go outside the nominal boundaries of 2 bytes presumed by COBOL ? If so, this is hardly an issue specific to COBOL. Presuming evil-code can play address arithmetic issues, any situation where the caller's address space is visible to evil-code is similarly vulnerable. Clearly evil-code should be in a separate address space to defend against such an attack. -- 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. ___
Re: [SC-L] Mainframe Security
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 <[EMAIL PROTECTED]> 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 <[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. > ___ > > -- Johan Peeters http://johanpeeters.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. ___
Re: [SC-L] Mainframe Security
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 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? A program that improperly releases data due to programmer error is beyond what I consider to be the realm of security. To me that is merely bad programming. To me the criterion is whether an outsider can cause a program to do something other than what it does for normal users. Some secret back door password that causes organizational secrets to be released would be a Trojan horse. A typical method of controlling that is with the security controls on a database, so only authorized users can read the "company secret" field, no matter how badly the application programmer messes up. -- 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. ___
Re: [SC-L] Mainframe Security
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. ___
Re: [SC-L] Mainframe Security
When all else fails, your need to answer four questions: 1) Is it authorized by the management that answers for the results of processing? 2) How do you know if the processing and resulting data are complete? 3) How do you know the results of processing are accurate? 4) Can the results of transaction processing be traced throughout any part of the application process without omitting or diluting the answers to the previous 3 questions? I have to attribute my answer to Mr. Hugh Hardie of Missasuagua, Ontario, CA, who made a inspired presentation to the Illini Chapter of ISACA very many years ago. I wish that his hunger to inspire others to pursue risks in their IS environment continues. Ed McGovern, James F (HTSC, IT) wrote: > I was thinking that there is an opportunity for us otherwise lazy > enterprisey types to do our part in order to promote secure coding in an > open source way. Small vendors tend to be filled with lots of folks that > know C, Java and .NET but may not have anyone who knows COBOL. > Minimally, they probably won't have access to a mainframe or a large > code base. > > Being an individual who is savage about being open and participating in > a community, I would like to figure out why my particular call to action > is. What questions should I be asking myself regarding our mainframe, > how to exploit, etc so that I can make this type of knowledge open > source such that all the static analysis tools can start to incorporate? > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > > > ___ > 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. > ___ > > > ___ 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. ___
Re: [SC-L] Mainframe Security
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. ___
Re: [SC-L] Mainframe Security
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. ___
Re: [SC-L] Mainframe Security
On Nov 1, 2007, at 4:16 PM, Johan Peeters wrote: sSince 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? Just a couple random(ish) observations here... 1) I believe that COBOL is still behind the *vast* majority of financial transactions today. I don't know the %, but I'd bet it to be close to 100%. 2) It's been my experience that COBOL folks (read: "mainframe programmers") tend to frown on the Internet, the web, and such. However, in talking with them, it's often useful to say that they're likely to have to interface with "internet folks" via SOA and other mechanisms, so it's worth their while to understand the security problems that "those guys" face, such as XSS and SQL/XML injection (a handy tip I picked up from Andrew van der Stock -- thanks Andrew!). So what's my point? It's this: I've often found the "mainframe crowd" to be reluctant to even talk about software security because there seems to be a pervasive attitude that it's not their problem. After all, the mainframe architectures they're familiar with have had secure, trustworthy networks and such for decades, right? Well, easing them into a discussion by simply pointing out that they should be aware of the issues that the "internet folks" have to deal with because they *need* to interface with them can help things along. Lastly, I noticed that at least one static code analysis tool (Fortify) now supports COBOL. I'm not yet sure what things they scan for, and I'm *far* from COBOL literate myself, but I figure it's got to be good news re James's point. Cheers, Ken - Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com smime.p7s Description: S/MIME cryptographic signature ___ 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. ___
Re: [SC-L] Mainframe Security
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? kr, Yo On 11/1/07, McGovern, James F (HTSC, IT) <[EMAIL PROTECTED]> wrote: > I was thinking that there is an opportunity for us otherwise lazy > enterprisey types to do our part in order to promote secure coding in an > open source way. Small vendors tend to be filled with lots of folks that > know C, Java and .NET but may not have anyone who knows COBOL. > Minimally, they probably won't have access to a mainframe or a large > code base. > > Being an individual who is savage about being open and participating in > a community, I would like to figure out why my particular call to action > is. What questions should I be asking myself regarding our mainframe, > how to exploit, etc so that I can make this type of knowledge open > source such that all the static analysis tools can start to incorporate? > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > > > ___ > 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. > ___ > -- Johan Peeters http://johanpeeters.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. ___
