So I’ve agreed on a general topic for my Msc thesis with my supervisor, the basic idea being to take a known vulnerability and from that to generate a shellcode executing exploit. Obviously there are a bucket load of problems that this summary glosses over but I intend to start out fairly basic with a vanilla stack overflow and work my way towards more interesting vulnerabilities. Given the time I’d also like to deal with protection mechanisms e.g. ASLR, DEP etc.

There doesn’t seem to be any published research that actually deals with this topic exactly. [1] describes a mechanism for specifing API level exploits, that is exploits that are a result of a sequence of API calls that results in some safety property being violated. They also treat printf like an API and describe how to automatically generating format strings that read/write arbitrary values and locations. The main issue with their approach is that it only deals with format string exploits, which are fairly trivial, and it requires manual reverse engineering to determine certain paramaters required in the exploit (like the buffer length available).

The only other paper I have found is [2], which describes a technique for automatically generating exploits based on a patched version of a program and the original. This is actually pretty cool although their definition of an ‘exploit’ is different to mine. They consider an exploit to be any violation of a certain property, such as the return address of a stack frame being modified. Due to this definition what they actual generate are denial of service conditions as opposed to exploits that result in code execution*.

The opinion of a few people, and one that I can see the reasoning behind, is that automatically generating exploits for the majority of vulnerabilities just isn’t feasible due to the level of customisation required. We’ll see….

[1] Automatic Discovery of API-Level Exploits, V. Ganapathy
[2] Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications, D. Brumley

* After reading the paper a bit more closely (doh!) and talking with the authors, it turns out they did actually generate control hijacking exploits for some vulnerabilities. Apparently not much research was put into this particular part of the project though so there’s still plenty to look at.

So Python 3.0 was released last Wednesday after just over a year of release candidates. There are a bundle of changes, which are summarised on Python.org, but to get a real feel for how people are regarding this release and how this release will actually affect your code I recommend the blog stream from PlanetPython.org.

The feed has been inundated with posts during the past week on a variety of topics and the main reason for this post is to link to a few of the more interesting and reoccuring ones. I’ve divided it into sections for your viewing pleasure.

General release info
http://feeds.feedburner.com/~r/Jessenollercom/~3/474718662/ - Release info from the maintainer of the new multiprocessing code
http://pieceofpy.com/index.php/2008/12/04/python-30-final-release/ - A summarised list of some interesting changes

Problems?
http://pybites.blogspot.com/2008/12/is-it-all-futile.html - Well, is it?
http://holdenweb.blogspot.com/2008/11/dont-use-python-30-really.html - Some common sense reasoning for not jumping on the 3.0 ship

Code samples and porting
http://www.voidspace.org.uk/python/weblog/arch_d7_2008_12_06.shtml#e1041 - Some info on the new string encoding/decoding
http://rhodesmill.org/brandon/2008/comprehension-consistency-at-last-in-python-30/ - A demo of the shiney new comprehensions for dictionaries and sets
http://farmdev.com/thoughts/66/python-3-0-on-mac-os-x-alongside-2-6-2-5-etc-/ - Getting 3.0 running on OS X alongside 2.X
http://feedproxy.google.com/~r/BeginningPythonForBioinformatics/~3/AMOkekz11Fk/ - A small demo of the new print syntax
http://wiki.python.org/moin/PortingToPy3k - The official porting wiki
http://sayspy.blogspot.com/2008/12/getting-help-with-porting-your-code-to.html - What it sounds like
http://lucumr.pocoo.org/cogitations/2008/12/07/porting-to-python-3-dos-and-donts/ - Ditto

An interesting back and forth over the merits of breaking backwards compatibility
http://mooseyard.com/Jens/2008/12/python-30-whats-the-point/
http://www.b-list.org/weblog/2008/dec/05/python-3000/
http://pkaudio.blogspot.com/2008/12/fear-uncertainty-and-doubt.html

(The next two relate to the above discussion but aren’t in response to anyone in particular)
http://blog.amber.org/2008/12/05/the-python-30-kerfuffle/
http://news.ycombinator.com/item?id=387248

The European Court of Human Rights announced today that the retaining of DNA by the British police of two men that were never convicted of a crime was unlawful and “could not be regarded as necessary in a democratic society”.

So what does the esteemed Home Secretary have to say on the matter? Well, apparently she is “disappointed” by the decision. So, keeping in mind that this was a unanimous decision, delivered by 17 European judges one would expect an exceptionally strong counter-argument in favour of this sort of data retention. What does ol’ Himmler come out with? Well, we were treated to the following:

“DNA and fingerprinting is vital to the fight against crime, providing the police with more than 3,500 matches a month.”

Excellent, cheers Jacqui. Well that surely justifies intruding on the basic human rights of an entire nation. Of course, if we’re using that metric as a measure of success then why don’t we just tag everybody like cattle and record their movements 24/7? I say this tongue-in-cheek but it can’t be that far off given the mentality of the current Home Secretary.

The thing that really bothers me about this is that nobody seems that outraged by the consistent and dangerous attitudes expressed by this woman. When the plans for a 42 day detention period were shot down she announced “I deeply regret that some have been prepared to ignore the terrorist threat, for fear of taking a tough but necessary decision.”. Oh, very clever. Expose those pinko liberals for the cowards they really are! Given the assumption that most people see through this kind of statement as cheap scare-mongering why would she feel the need to use such pathetic rhetoric? Is she actually stupid or is she getting so comfortable in her position and ’security measures’ that she no longer feels the need to justify her arguments in an intelligent fashion?

Not long after the above 1984-esque piece of magnificence Smith announced that given a terrorist attack she would ignore the annoyingly democratic vote down of the bill and just implement it via special legislation anyways. Grrrreat!

I know I’m not the only one that sees the irony in attempting to ‘fight terrorism’ by imposing draconian laws on a primarily law-abiding populace, so one has to assume that the people passing these laws are similarly aware. So what is the motivation? Is it just natural that once someone is in power they will attempt to pass anything that will strengthen their position and can also be passed as ‘for the greater good’? Am I too cynical? Are they just plain stupid?

I’ve been playing around with the Windows Driver Kit (WDK) for the past few days and come across a few (non code related) slip ups.

The first of which, revolved around finding the DDK. Apparently, the previously easy to guess URL (http://www.microsoft.com/ddk) made things far too easy for people, and Microsoft…being Microsoft…decided to spice things up a little. To retrieve the DDK (now called/part of the WDK) you have to navigate to http://connect.microsoft.com, ignore the guy in the shirt that looks like he’s about to sell you a sofa, realise that a ‘Connection’ is MS speak for ‘Download’, follow a series of nested links, click around a bit and eventually/accidentally land on the desired page.

But, I hear you cry, surely I could just search Google? Erm..well..no, it would appear they’ve decided, in their infinite wisdom, to hide the download link from search engines. Ah, well..that’s OK, surely their own search engine can find it? Again..not quite, you can search on http://connect.microsoft.com alright but it would appear that the links it returns for the WDK are entirely broken. Just grrreat!

The second ‘inconvenience’ was in attempting to set up Visual Studio Express C++ edition (VSEC++) to work with the WDK. This cost me a good hour of my life so I may as well document the process.

1. Get DDKBUILD. This is a script that can be called by VSEC++, take care of finding the necessary WDK scripts and invoke them. Move it to a location in your PATH.

The rest of the process is a modified version of what’s found here so I’ll just point out the parts that seemed non-obvious.

2. Create a new project in VSEC++ and select the ‘Makefile Project’ option. Create the project at a location with no spaces in the path as the build script from the WDK dislikes those apparently.

3. The build/rebuild commands that you can enter as part of the wizard will differ depending on your system. For me they looked like ‘ddkbuild -XPBASE checked “FULL_PATH_TO_SOURCE”‘. The path to your project source will be a subdirectory of the location you decided on earlier, named after the project. For me it looked like “C:\vsprojects\driverproject\driverOne\“. You must also ensure that you have set the XPBASE environment variable (or whichever variable your system depends on as documented in the DDKBUILD help). Set it to point to the location of your WDK install. For me this was “C:\WinDDK\6001.18001\“.

4. For a driver project you will also need to create two other files, MAKEFILE and SOURCES. Place these in the same directory as your source code. Apparently the build script doesn’t like using subdirectories in the SOURCES variable of the SOURCES file so if anyone finds a way to specifying things like ‘subdir/mycode.c‘ please let me know.

5. If you add a new file to your project and want to avoid C++ name mangling then either enclose it in an ‘extern “C” {}’ tag or rename the file with a ‘.c’ extension after it has been created. This will be necessary for your DriverEntry function.

All of that should be enough to allow you to build your project through VSEC++. Unfortunately, this doesn’t help with common features enjoyed when building userland code though e.g. highlighting the lines causing compile time errors in the IDE. As a result, I’m still having to trawl through the output of the build log for that kind of info. If anyone has a nicer way of getting the same kind of assistance you get with userland code when developing drivers I’d appreciate the heads up.

BTW, it was brought to my attention yesterday that Visual Studio Pro is available free to students through a MS site, rather flamboyantly, titled DreamSpark. Apparently, VS Pro has better driver development support so I’ll report back on that once I get around to installing it. There’s also a bundle of other free stuff there so it might be worth checking out.

I’ve been spending the vast majority of my free time for the last number of weeks reading papers on a variety of topics related to automated verification, model checking and language/text processing. I’ve encountered some that were interesting, some that were ‘meh’ and a substantial few that were nothing short of complete and utter tripe. Anyways, I figured it would make for an interesting ‘theme’ to post a link to one paper a week for the next number of weeks covering the general topic areas that I’m researching at the moment.

So, to get the ball rolling is a paper I first read just over a year ago and ‘rediscovered’ earlier this week. The paper is ‘Automated vulnerability auditing in machine code’ from Phrack #64. It discusses and encourages a method of automatically discovering buffer overflows, integer conversion issues and other common attack vectors. The method described is quite a lot different to fuzzing and is based on a foundation of formal verification methodologies and techniques that have been common in hardware verification for a number of years.

This is an interesting approach and one that will probably gather a lot more attention in coming years. For hackers and vulnerability researchers the frustrations of fuzzing often lead to a desire for something ‘better’. Anybody that has written and used a fuzzer is familiar with the feeling that occurs when a vulnerability isn’t found. How much did you *really* test? How effective is the, essentially random, search through the program’s state space? Most people eventually yearn for a more ‘intelligent’ type of fuzzing and as a result all sorts of techniques and tools have cropped up. Almost all are based on the same initial premise of a generation/mutation based fuzzer that instruments the target application for some form of feedback though[1][2][3]. This paper provides a good deal of encouragement for an approach with many similar goals as fuzzing but based on rather different foundations that would appear to deal with many of the drawbacks of current attempts at automated vulnerability discovery.

[1] Bunny the Fuzzer
[2] Autodafe
[3] EFS