Gary,

While I've not yet seen your _Exploiting Software_ book, I use
your _Building Secure Software_ as one of the texts for a graduate
CS class in security (http://cs.franklin.edu/Syllabus/comp676/).

Unfortunately, I've not seen any copies of your book in any major
bookstore in the Columbus, OH area, so appologies about my
naïvety in this area, but I've not had a chance to peruse it.

But I have one question regarding your "attack patterns"--and please
don't take this as a challenge. My question is, what makes you
and Hoglund's "attack patterns" so different from (say) the security
patterns as described by Yoder and Barcalow or by Mark Schumacher?

What makes "attack patterns" so different than the work done by
the OASIS Web Application Security technical committee (charter at:
http://www.oasis-open.org/committees/was/charter.php) that
is chaired by Mark Curphey, Peter Michalek, and your Citadel
colleague, David Raphael and had its roots in the OWASP ASAC
work started several years ago.

I'm not trying to accuse you of academic plaigarism, but am curious
in how you see your "attack patterns" fitting together in the
bigger picture along with the OASIS WAS work and the generic
security patterns work of Yoder, Barcalow, Schumacher, and others?
Or perhaps are they more like the CVE work maintained by Mitre?

What are the differences? What is the overlap? Can you point to
an online example of any documented attack pattern that you have
in the book so we can see one or a few of them? Why should I want
to use your attack patterns rather than one of these other efforts
I've mentioned?

Like I said, not only have I not _read_ your book, I've not even had
a chance to thumb through it.

I think it's good to try to catalogue such things, but I think it's
going in the wrong direction when there is little industry consensus
on exactly how to do this. Adding yet another classification scheme
is not valuable unless we can understand exactly what the new scheme
brings to the table and how it fits along side other similar attempts.

Also, one last thing... not to nitpick, but it seems that your 48 attack
patterns can be grouped into a few broader categories? Does your book
do this as well?

Thanks in advance for your response,
-kevin wall
---
Kevin W. Wall           Qwest Information Technology, Inc.
[EMAIL PROTECTED]       Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit



-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Gary McGraw
Sent: Fri 11/12/2004 8:39 AM
To: ljknews; Secure Coding Mailing List
Subject: RE: [SC-L] How do we improve s/w developer awareness?
 
One of the reasons that Greg Hoglund and I wrote Exploiting Software was
to gain a basic underdstanding of what we call "attack patterns".  The
idea is to abstract away from platform and language considerations (at
least some), and thus elevate the level of attack discussion.

We identify and discuss 48 attack patterns in Exploiting Software.  Each
of them has a handful of associated examples from real exploits.  I will
paste in the complete list below.  As you will see, we provided a start,
but there is plenty of work here remaining to be done.

Perhaps by talking about patterns of attack we can improve the signal to
noise ratio in the exploit discussion department.

gem

Gary McGraw, Ph.D.
CTO, Cigital
http://www.cigital.com
WE NEED PEOPLE!

Make the Client Invisible
Target Programs That Write to Privileged OS Resources 
Use a User-Supplied Configuration File to Run Commands That Elevate
Privilege 
Make Use of Configuration File Search Paths 
Direct Access to Executable Files 
Embedding Scripts within Scripts 
Leverage Executable Code in Nonexecutable Files 
Argument Injection 
Command Delimiters 
Multiple Parsers and Double Escapes 
User-Supplied Variable Passed to File System Calls 
Postfix NULL Terminator 
Postfix, Null Terminate, and Backslash 
Relative Path Traversal 
Client-Controlled Environment Variables 
User-Supplied Global Variables (DEBUG=1, PHP Globals, and So Forth) 
Session ID, Resource ID, and Blind Trust
Analog In-Band Switching Signals (aka "Blue Boxing") 
Attack Pattern Fragment: Manipulating Terminal Devices 
Simple Script Injection 
Embedding Script in Nonscript Elements 
XSS in HTTP Headers 
HTTP Query Strings 
User-Controlled Filename 
Passing Local Filenames to Functions That Expect a URL 
Meta-characters in E-mail Header
File System Function Injection, Content Based
Client-side Injection, Buffer Overflow
Cause Web Server Misclassification
Alternate Encoding the Leading Ghost Characters
Using Slashes in Alternate Encoding
Using Escaped Slashes in Alternate Encoding 
Unicode Encoding 
UTF-8 Encoding 
URL Encoding 
Alternative IP Addresses 
Slashes and URL Encoding Combined 
Web Logs 
Overflow Binary Resource File 
Overflow Variables and Tags 
Overflow Symbolic Links 
MIME Conversion 
HTTP Cookies 
Filter Failure through Buffer Overflow 
Buffer Overflow with Environment Variables 
Buffer Overflow in an API Call 
Buffer Overflow in Local Command-Line Utilities 
Parameter Expansion 
String Format Overflow in syslog() 





Reply via email to