mark June 13th, 2008
I had intended to post a blog entry here concerning the MJPEG disclosure in the recent MS drop. This is basically one of the bugs John and I were alluding to at CanSecWest earlier this year when discussing vulnerabilities in Windows media software. However, one of the joys of working for an employer with a blog is that I have to contribute to it as well as this one. So, rather than repeat the same post twice, I will redirect you to my post on ISSs blog: http://blogs.iss.net/. (It is currently the second post from the top.)
mark May 9th, 2008
I know the blog has been fairly quiet lately, but as you can see, I’ve been busy doing some Internet research.
mark April 22nd, 2008
Hey there,
As we mentioned a while ago on this blog, John and I presented at CansecWest on finding vulnerabilities in Windows media software. We have uploaded the slides now to our website, and you can download them here.
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 I’d 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 protocol’s 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. Here’s 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:
- The browser issues a GET request for the desired URL with a Method-Check header listing the method of the request that will follow.
- The server responds with access-control headers telling it what methods are allowed or denied for a particular set of origins.
- If the origin and method combination are allowed, the browser issues the cross-site POST request.
Now, this certainly adds some complexity to the browser implementations, but overall it isn’t 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? I’d expect that it’s 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 I’d maintain that information is already more than easy enough to get when spidering the site. Finally, doesn’t 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 can’t 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!
