Re: [SC-L] COBOL Exploits

2007-11-18 Thread Andrew van der Stock
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  

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.

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
gives these COBOL-related RISKS items.  The initial
character descriptors are defined there.  In the citations,

* R relates to RISKS (archives at
* S relates to SIGSOFT Software Engineering Notes (archives at 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  

 (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)

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)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC ( 

as a free, non-commercial service to the software security community.

Andrew van der Stock
Executive Director, OWASP
Lead Author, OWASP Guide

Description: S/MIME cryptographic signature
Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Re: [SC-L] Mainframe Security

2007-11-18 Thread Andrew van der Stock
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  

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.


Description: S/MIME cryptographic signature
Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -
SC-L is hosted and moderated by KRvW Associates, LLC (
as a free, non-commercial service to the software security community.

Re: [SC-L] OWASP Publicity

2007-11-18 Thread Benjamin Tomhave
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

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.



Benjamin Tomhave, MS, CISSP

[ 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.