Re: [SC-L] COBOL Exploits
I've been researching web app - mainframe security from a software engineering perspective for about the last six months. If anyone from a mainframe background wants to collaborate, I'd be more than happy to share as I have a few challenges: a) I'm working from secondary resources (web pages, manuals, PDFs) b) I don't have access to a z/OS or similar system and thus cannot mock up a test environment to prove or disprove my hypotheses on how best to prevent certain classes of attack c) I really don't have a lot of experience with z/OS, COBOL, DB2, IMS, or CICS. Therefore, I could be missing some great resources and features. Saying that, I have made a bit of headway by applying first principles and trying to discover what is available to assist and protect against certain threats and attacks. I've just posted a draft entry to my blog detailing the first (and I mean first) post I've had brewing since May this year. It's nowhere near as good as I would have liked. I don't do exploits. You will not be seeing any how to hax0rs b1g ir0n from me. I don't see the relevance of arming script kiddies. Only the architects and developers need to know how to develop and maintain safer designs and code, and folks like me need to know what to look for to make sure it's in place. That said, from my personal research, this area is a total greenfield. The folks who know mainframe security simply don't come out of their shells often enough. They have the goods, but the goods are not really well known amongst the architects and devs I've dealt with. Most of the business folks who ask for their shiny new dodgy code to talk to old dodgy transactions don't see this risk and refuse to pay to have qualified folks review and remediate the security of the mainframe side. They see it as this reliable old workhorse - which is not broke, so don't fix it. And in my personal experience, they NEVER fix it. On another note, I'm really happy to see Fortify tackle the mainframe with their SCA products. It's really late and delayed, but better late than never. I know a bunch of sites that could use that tool if it works even 1% as well as the marketing is likely to make out. thanks, Andrew van der Stock Executive Director, OWASP Project Lead Author, OWASP Guide On Nov 2, 2007, at 1:45 PM, Peter G. Neumann wrote: 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 www.sigsoft.org/SEN/ although more recent items also in RISKS) Vf West Drayton ATC system bug found in 2-yr-old COBOL code (S 16 3, R 11 30) \$fe IRS COBOL reprogramming delays; interest paid on over 1,150,000 refunds (S 10 3:12) S[H?] Election frauds, lawsuits, spaghetti code, same memory locations used for multiple races simultaneously, undocumented GOTOs, COBOL ALTER verb allowing self-modifying code, calls to undocumented/unknown subroutines, bypassable audit trails (S 11 3); Report from the Computerized Voting Symposium, August 1986 (S 11 5) Sie Data transfer Excel-COBOL loses voter data in 2003 Greenville Mississippi election (R 22 95) \$hi Man gets \$218 trillion phone bill (R 24 24); COBOL program? (R 24 27,29,30,33) f Discussion of date and century roll-over problems: Fujitsu SRS-1050 ISDN display phones fail on two-digit month (10); 1401 one-character year field; COBOL improvements; IBM 360 (S 20 2:13) [See Fred Ballard and Walt Murray (R 16 70 ff).] [Lots of stuff is relevant on COBOL's two-character year field and the entire Y2K saga.] ___ 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. ___ Andrew van der Stock Executive Director, OWASP Lead Author, OWASP Guide 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
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] OWASP Publicity
I agree and disagree with these comments, as I think they possibly represent an outmoded way of thinking when it comes to IT management. Execs and senior mgmt _must_ have a certain understanding of security that will at least give them a basis for making risk decisions. It seems today that they are fine (generally) making business risk decisions, but then believe falsely that making an IT risk decision requires following a completely different set of rules (when, in fact, it's just another kind of business risk decision). I'm of the belief that this directly correlates to their lack of fundamental understanding of IT and security issues. Where I agree is the level of detail that needs to be imparted. OWASP Top 10 is probably too much detail to communicate to the average exec or sr manager. However, we must not overlook that these business leaders were once individual contributors. Yes, it's true that some of these folks came up through a strictly business route, but for the most part these days I see these careers originating in at least a semi-technical role. We should be seeking to leverage those backgrounds to educate them and bring them to modern times. On Crispin's later comments about bad vs good managers, I think he's very much hit the nail on the head (see the quote in my sig). However, there's one aspect that's overlooked, which is outdated prior history. If an executive's understanding of technology is founded in their first contributions as an individual contributor 10-20 years ago, then this means their understanding of modern technology may be severely limited. I'm sure all of us understand how difficult it is to stay on top of current trends as technology evolves, and it's often our job to do so. What if it's not your job to keep current? The times will change while your focus is elsewhere, but only a truly savvy person will think to check that context before making decisions that affect it. This seems to be a rarity. So, to conclude, I think that it would be valuable, in broad brush strokes, to educate leaders about secure coding - and security in general - but perhaps not to the level of detail we might really desire to see. We want execs and sr managers to drive their folks toward secure coding practices, but that doesn't mean they themselves have to know how to code securely. As such, in targeting these other publications, the message should be refined to be business-oriented, extolling the business risks associated with ignoring these practices and providing a big arrow pointing in the direct of orgs like OWASP. fwiw. -ben -- Benjamin Tomhave, MS, CISSP [EMAIL PROTECTED] Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave Blog: http://www.secureconsulting.net/ Photos: http://photos.secureconsulting.net/ [ Random Quote: ] If a man is offered a fact which goes against his instincts, he will scrutinize it closely, and unless the evidence is overwhelming, he will refuse to believe it. If, on the other hand, he is offered something which affords a reason for acting in accordance to his instincts, he will accept it even on the slightest evidence. The origin of myths is explained in this way. Bertrand Russell Crispin Cowan wrote: McGovern, James F (HTSC, IT) wrote: I have observed an interesting behavior in that the vast majority of IT executives still haven't heard about the principles behind secure coding. My take says that we are publishing information in all the wrong places. IT executives don't really read ACM, IEEE or other the sporadic posting from bloggers but they do read CIO, Wall Street Journal and most importantly listen to each other. What do folks on this list think about asking the magazines and newspapers to publish? I am willing to gather contact information of news reporters and others within the media if others are willing to amplify the call to action in terms of contacting them. The vast majority of IT executives are unfamiliar with all of the principles of security, firewalls, coding, whatever. The important thing to understand is that such principles are below their granularity; then are *right* to not care about such principles, because they can't do anything about them. Their granularity of decision making is which products to buy, which strategies to adopt, which managers to hire and fire. Suppose they did understand the principles of secure coding; how then would they use that to decide between firewalls? Web servers? Application servers? If anything, the idea that needs to be pitched to IT executives is to pay more attention to quality than to shiny buttons features. But there's the rub, what is quality and how can an IT executive measure it? I have lots of informal metrics that I use to measure quality, but they largely amount to synthesized reputation capital, derived from reading bugtraq and the like with respect to how many vulnerabilities I see with respect to a given product, e.g.
