Creating the OpenSAMM Roadmap Document

Lately, we've been doing some work with OpenSAMM to help our clients improve security in their SDLC.  This framework is very simple and supplies a method for creating a roadmap to drive your efforts to secure your software development projects.  The formal charts used in the official OpenSAMM are apparently generated by Adobe Illustrator which I don't have.  I'm a proponent of stimulating graphics, particularly in artifacts that will be dissemenated across diverse groups of skillsets.  Since the roadmap document is something that will be used to communicate with executive management the intentions and timeframe to implement OpenSAMM, I wanted to make sure it was visually appealing.  Rather than an Excel chart I wanted to get as close to the real thing as possible.

While searching the Internet I stumbled upon a 3 part blog series that detailed an effort to create a method that used XML and Scalable Vector Graphics (SVG) to create a nice-looking roadmap artifact very similar to the graphs shown in the official OpenSAMM document.  These blog entries go into informative detail about the story of how the author created the format but don't have a definitive set of steps in one easily accessible place.

This blog entry is intended to be summary version of the steps needed to quickly create a roadmap document.  For those of you that are curious about the underlying technical details please see the aforementioned blog entries hyperlinked below:

1. Part 1
2. Part 2
3. Part 3

For those that just want to cut to the chase follow the steps outlined below:

1. First download the archive files here and here and extract the zip archives and place all files in the same directory
2. Using your favorite text editor (preferrably one with XML syntax highlighting), edit roadmap-ex1.xml to match the goals you have set for each security practice.  The file format is very straight forward.
3. Use a tool like Apache Xalan to create the SVG file.  If you are using xalan the command syntax I used to generate the .svg output file was as follows:

xalan -o roadmap.svg roadmap-ex1.xml SAMM-1.0-roadmap-0.6-en_US.xsl  

Note: xalan syntax may vary slightly between versions.  See the documentation associated with your xalan installation if this syntax does not work for you.

You're done.  Your roadmap.svg file can be opened in most browsers and you should have your roadmap document as roadmap.svg openable in most browsers.  Please note that you will need to include the file SAMM-1.0-roadmap-0.4.css whenever distributing the .svg file so that it will properly render in a browser.

I would like to thank Pravir Chandra for creating OpenSAMM, Colin Watson and Brenda Larcom for their great work on the XML, XSLT, and SVG files, and lastly the OWASP community at large for doing an outstanding job of making it easier to secure web applications.

Locating Dangerous Functions with IDA Pro

During a black box COTS application assessment, we wanted to identify dangerous functions that could possibly be abused to gain code execution. Flawfinder, an elementary source code focused tool designed for exactly this purpose was a good starting point. Embedded in the source code are a good list of functions that are considered dangerous.

Four problems with flawfinder:

1. It only works on the source code. No COTS products for me.
2. Signatures are embedded in the code. Not easily reusable.
3. Not supported (last update 2007). I've submitted a patch to Dan Wheeler (the flawfinder author) before and never heard back.
4. Not exhaustive. I think Michael Howard did a great job changing the Microsoft SDL to prohibit certain functions from being used for software development.  Flawfinder doesn't include many of these functions.

I decided to attempt a little experiment and port some of the flawfinder functionality to IDA Pro. In the end, I moved the flawfinder database to raw XML and added the functions that Michael Howard banned from the Microsoft SDL. My XML file describing dangerous functions is available here.

SHA256: 6695bb84bd1e9536c930b3599426cca04bfc02b31d66d9a61ca00ac7f0e1a686

MD5: c6b712a94962dd583974fa34ba19e23f

Please let me know if you would like to submit any additional functions and I will add them to the file. In the future I will probably modify flawfinder to use this xml database as well.

I also created a little python script using IDA python that iterates over function names and finds any references to known dangerous functions. We are using these references as input for mynav in order to calculate execution pathes that may lead to exploitable situations which in turn helps us to tune our fuzzers. My dangerous_functions.py script for achieving this is available here.

SHA256: bac5d21a7861b4387c0600ed5e825029e10560ab2fad33984ffa935342101f5f

MD5: be6c18777e755662a5fcccdb697dbd93

In order to use it, you may have to modify the 'dangerous_functions_file' on line 7 of the aforementioned dangerous_functions.py script in order to accurately point to your location of dangerous_functions.xml. Then load up the binary in which you want to locate dangerous functions in IDA Pro and run the following ida python command

execfile(r"C:\path\to\dangerous_functions.py")

Please note that this script is just an experiment (Read: primitive) and makes no attempt to actually verify if the functions are being used safely or not.  Additionally, please note that this script was developed and tested using IDA Pro 6.0 and IDApython version 1.4.3.

I would like to thank Dan Clemens of Packet Ninjas for inspiration and of course the hex-rays team for such a great tool. I would also like to thank Dan Wheeler for writing flawfinder and Michael Howard for doing such a great job improving the Microsoft SDL and releasing the information for general consumption. Don't hesitate to drop us a line to offer constructive criticism or offer improvements/suggestions.

Please note Halvar provides a similar project though I have not yet thoroughly reviewed the source:

http://sourceforge.net/projects/bugscam/

Also, this project looks interesting as well:

http://sourceforge.net/projects/ida-pro-code/

RE-Google and IDA 6.0

During the course of doing a black box security audit on a COTS application, we noticed that RE-Google had been broken.  A lot of changes have been happening in the IDA Python API over the last several revisions causing a lot of breakage of our old and familiar tools.  I found someone who had made it work on IDA 5.7 at this link here. But even using the script linked there, we were still getting this weird error:

Traceback (most recent call last):

  File "<string>", line 1, in <module>

  File "D:\share\regoogle\regoogle.py", line 721, in <module>

    re_google(SEARCH_ALL_FUNCTIONS)

  File "D:\share\regoogle\regoogle.py", line 347, in re_google

    if query4function(func):

  File "D:\share\regoogle\regoogle.py", line 293, in query4function

    res = search4files( l )

  File "D:\share\regoogle\regoogle.py", line 206, in search4files

    results = client.GetSnippetsFeed( query )

  File "D:\Python26\lib\site-packages\gdata\codesearch\service.py", line 84, in GetSnippetsFeed

    feed = self.Query(query.ToUri())

  File "D:\Python26\lib\site-packages\gdata\codesearch\service.py", line 71, in Query

    return self.Get(uri, converter=converter)

  File "D:\Python26\lib\site-packages\gdata\service.py", line 1074, in Get

    return converter(result_body)

  File "D:\Python26\lib\site-packages\gdata\codesearch\__init__.py", line 136, in CodesearchFeedFromString

    return atom.CreateClassFromXMLString(CodesearchFeed, xml_string)

  File "D:\Python26\lib\site-packages\atom\__init__.py", line 93, in optional_warn_function

    return f(*args, **kwargs)

  File "D:\Python26\lib\site-packages\atom\__init__.py", line 128, in CreateClassFromXMLString

    return _CreateClassFromElementTree(target_class, tree)

  File "D:\Python26\lib\site-packages\atom\__init__.py", line 164, in _CreateClassFromElementTree

    target._HarvestElementTree(tree)

  File "D:\Python26\lib\site-packages\atom\__init__.py", line 186, in _HarvestElementTree

    self._ConvertElementTreeToMember(child)

  File "D:\Python26\lib\site-packages\atom\__init__.py", line 295, in _ConvertElementTreeToMember

    _CreateClassFromElementTree(member_class, child_tree))

  File "D:\Python26\lib\site-packages\atom\__init__.py", line 164, in _CreateClassFromElementTree

    target._HarvestElementTree(tree)

  File "D:\Python26\lib\site-packages\atom\__init__.py", line 194, in _HarvestElementTree

    self.text = tree.text.encode(MEMBER_STRING_ENCODING)

  File "D:\Python26\Lib\encodings\utf_8.py", line 18, in decode

    return codecs.utf_8_decode(input, errors, True)

AttributeError: 'NoneType' object has no attribute 'utf_8_decode'

I was able to fix this error by modifying \Python26\Lib\encodings\utf_8.py and the decode() function.

I essentially changed it to the following:

def decode(input, errors='strict'):

    import codecs

    return codecs.utf_8_decode(input, errors, True)

Adding the line 'import codecs' appears to fix any RE-Google issues and make it work with IDA Pro 6.0.  Not sure why this problem exists.  I tried to do some basic checking in gdata to ensure usage of the API was correct.  Everything looked right.  I even tried to use gdata 2.0.4 which the RE-Google author stated in the README file he used for development: same error.

Anyhow, you may download my version of RE-Google here which has been tested and confirmed to work with IDA Pro 6.0.

Sha256: 9a01eb0743964b9aed9aa77a20ce3b69f6871309a5e4d5fa1a01bb9c22f9ac34

MD5: bfb59c1f5d846f49a9afc4e13f76721a 

I'd like to offer my thanks to Felix Leder for writing RE-Google, Elias Bachaalany for porting RE-Google to IDA 5.7, and of course hex rays for writing IDA Pro in the first place.