mark April 12th, 2008
Adobe released a patch recently for the Flash Player application that addresses several vulnerabilities, one of which I discovered. Although it initially seemed like the ability to exploit this bug was fairly limited, I found an interesting methodology that I was able to use to reliably exploit the bug. I have documented the details of it for interested readers here.
Enjoy!
mark February 26th, 2008
Hi there,
As Justin indicated in his last post, he and I will be delivering a “dojo” class on finding vulnerabilities in contemporary C/C++-based applications. We have really tried to focus on delivering fresh and interesting material on the subject, rather than just regurgitating the same old stuff you have heard 100 times before (although, admittedly, some of that stuff is necessary). Our goal is to create a class that will examine not only vulnerability classes, but the processes that you need to follow to find those spicy 0day bugs. The stuff I have put in has proven successful for me, and hopefully will give attendees insight into the practical application of vulnerability knowledge on high-value targets.
In other news, I am also giving a talk at CansecWest with John McDonald on Windows Media stuff. Here, we are going to discuss the various media architectures prevalent on Windows OSs for developing both filters (codecs) and playback software. After touching on the architecture, we will discuss enumeration of attack surface and how to go about auditing media-based software (codecs in particularly) for vulnerabilities. It turned out that due to time constraints (our speech is 1 hour), we will not be able to present all the material we have prepared in its entirety, however we will probably leave all the content in the slides that get posted on the website.
Hope to see you all there!
justin February 22nd, 2008
The Dojo announcements for this year’s CanSecWest just came out and you may have noticed that Mark and I are teaching Vulnerability Discovery Demystified on March 25 in Vancouver. This course pairs up with the content from “The Art of Software Security Assessment,” and provides students with hands-on experience finding security bugs in real code. The Dojo page has the description and prerequisites, so I won’t go into more detail. I just thought you guys might want to be interested in case you know someone looking for a crash course on bug hunting.
justin January 10th, 2008
I honestly thought that Id covered all the ground I could on same-origin policy, but I just stumbled across the W3C draft on Access Control for Cross-site Requests. Apparently, this is implemented in the upcoming Firefox 3 and (given the author) can be expected to show up in Opera too. It seems this protocols sole purpose is to allow cross-site XMLHttpRequests to get through the same-origin policy. I admit serious dismay that no one is taking the opportunity to shore things up a bit while making new holes (especially considering my previous thoughts on the subject). However, I understand that developers are probably clamoring for the chance to make shiny new AJAX mashups and widgets. That said, I cannot understand is how this particular solution is the best we can get. Heres a rough explanation of how the protocol works:
For a cross-site GET, the request is issued, and the response is checked for access-control headers (or header directives in the document), which determine what requesting domains are allowed to make cross-site requests. If the requesting domain is allowed, the response is made available to the script; otherwise, it fails.
A POST (or DELETE) is a bit different, and is handled in multiple steps in order to prevent unwanted side effects:
Now, this certainly adds some complexity to the browser implementations, but overall it isnt too bad. The protocol also includes authorization caching to reduce the chattiness. However, things get much more complicated when you look at the server. One notable fact is that access-control logic will have to be implemented for every server page that handles cross-domain requests. So, rather than consolidate things into one easy to audit policy file, the logic will instead be spread out across potentially any page on the site (because even the static pages can include access-control directives in XML headers). You can also expect to see a lot of mistakes with the POST handling.
So, I have to ask, what is the value in spreading the origin policy exceptions across the entire web site? Id expect that its going to make web-app security auditing a whole lot more complicated. I will preempt the argument that a policy file would expose site structure and cross-site relationships, as Id maintain that information is already more than easy enough to get when spidering the site. Finally, doesnt anyone else care about shoring up all the existing cross-site stuff so we have a little more defense against things like XSS and XSRF? Because I cant see any way of Access Control for Cross-site Requests ever addressing the security problems we currently see every day.
jm January 10th, 2008
Congrats to Alex and Ryan for breaking the Internet! I think that, by all objective standards, they have won and we can all stop trying now.
mark August 7th, 2007
Hi!
Well, we just arrived home from Las Vegas on Sunday after delivering our talk at Blackhat about breaking C++ applications. It seemed to be received pretty well. For anyone interested, the slides should be available on their website, but we have also archived them here.
Enjoy!
mark July 9th, 2007
Hi there!
We would like to announce that we will be speaking at Blackhat in Las Vegas (beginning August 1) this year on the topic of C++. The basic premise for the speech is this: Most security literature about vulnerability analysis (or secure programming) for C/C++ tends to only address potential problems that can occur in C (dangerous API calls, integer overflows, pointer arithmetic, and so on). While these problems also affect C++, it is very rare that C++-specific problems are dealt with at all. As such, we are going to speak to a few problems that are specific to C++ and C++ runtime environments. There is too much material to address every potential problem that can occur in C++ in the time we have, but some of the things we intend to cover include VLA’s, the STL, and exception handling. So, if this sounds like your cup of tea, swing by and check it out!
We will also be doing a book signing on the first day of BlackHat at 12.30 PM.
Hope to see you there!
blog February 20th, 2007
Our service provider is performing maintenance, so TAoSSA.com may be unavailable on Wednesday 21 February sometime between 12AM EST (-0500 GMT) to 8AM. I guess this is what we get for basing our budget on the change we found in John’s couch cushions.
We expect the actual outage to be brief and weren’t planning on posting anything new during that period anyway. Besides, our Google rank proves that you really come here for only one thing: Death Bunnies. Fortunately they’re hosted elsewhere on redundant, fault-tolerant, load balanced servers.
justin February 17th, 2007
Last week I presented an overview of the same-origin policy and different attacks against it. This week I’m going to take a cue from Robert Seacord and propose a solution to the problem. It’s probably not the ideal solution, but maybe it will start some discussion and lead to something more complete. I had also intended on exploring some related proposals first, but I’ve decided I’ll present my own idea before I start a debate on other suggestions.
mark February 13th, 2007
Hi guys,
In a post we did recently, we pointed to informit, who is selling our book at a 40% discount. However, due to a mixup with ISBNs, both informit and AW Professional marked our book as unavailable, and so you were unable to actually purchase it at either of these sites. Well, the problems seems to have finally been resolved, and the sale still appears to be running. Get it while it’s hot!
This blog provides running commentary from Mark Dowd, John McDonald, and Justin Schuh, the authors of the book: The Art of Software Security Assessment. You can purchase a copy from Amazon, or directly from the publisher, Addison-Wesley, and peruse the sample chapter on C Language vulnerabilities.