Q&A: Mark Dowd on NULL pointer dereference bugs

Mark Dowd’s 25-page paper on NULL pointer dereference bugs has caused quite a stir in security circles. He speaks to Patrick Gray in this Q&A.

IBM ISS researcher Mark Dowd took a NULL pointer dereference bug in Adobe’s Flash client -- which most people would assume couldn’t be exploited -- and exploited in with incredible style. His 25-page paper on the bug and its exploitation has the entire security community talking. The following is a transcript of Mark Dowd’s interview on the Risky Business security podcast.

Mark Dowd (MD): The paper itself discusses a specific vulnerability in Flash and basically it outlines the vulnerability which is the NULL pointer type vulnerability. It also discusses in depth an exploitation technique for leveraging that vulnerability to gain reliable and remote access to machines running Flash. There has been a lot of attention drawn to the paper for two reasons. One is because Flash is really widely deployed and is available on UNIX, Windows, Mac and a range of embedded devices and so a major vulnerability in Flash is a pretty big deal.

The other reason is that with NULL pointer type vulnerabilities, people don’t really concentrate on them... except in a few specific cases, and have sort of assumed that they are unexploitable for the most part. That is not always the case which is what this paper is illustrating.

Patrick Gray (PG): I believe that back in 2006 -- I am looking at a little bit of a blurb here on Uninformed.org -- there was some research going into NULL pointer dereferences. But what you have done is taken it a step further and it really is the method of exploitation that has got people excited here isn’t it?

MD: Yeah. The thing in Uninformed.org was addressing a slightly different issue. There has been a number of papers and investigations into NULL pointer dereferences in the past and a lot of them in the past have focused on basically operating system level vulnerabilities where you are able to get a valid page mapped at the base address of a process. So basically any dereference from NULL will be exploitable or something. There are a few papers on that -- the Uninformed one that you mentioned and there was another one specifically in the context of ARM processes that Barnaby Jack did last year.

PG: I was actually going to get to that. That was a pretty big deal and that caused quite a stir in the area of embedded devices.

MD: Yeah. So he was basically outlining how in a lot of cases on embedded devices you can exploit your standard NULL pointer dereference because there is a pretty important vector table mapped at that address. The vulnerabilities that I discovered was basically where a memory allocation failed so a NULL pointer was returned and the address written to wasn't NULL it was NULL plus some offset. That offset was more or less controllable by the user so when you add NULL with this valid and arbitrarily large offset you can actually write to a valid region in memory and often you can leverage that to execute arbitrary code or do whatever you want.

PG: I spoke to H D Moore earlier today -- he's next week's guest on Risky Business -- and he basically said most people, when confronted with these sort of bugs, are not really even going to look at figuring out how to exploit them because... you are never really going to be able to do it that successfully anyway. So what on earth possessed you to actually do this research that no one else seems to have got around to?

MD: Basically it was a special case... I looked at and at first it just seemed like a NULL pointer dereference which usually results in a crash and which is not particularly exciting in the context of Flash.

But I realised that the way that the way the code was structured that you could actually write to a location other than NULL and I used this information and went forward and said well OK, what could I do that could be useful here and because I had done a fairly extensive application review of Flash I was aware of the workings of how the virtual machine worked quite intimately and so it was the first thing that occurred to me.

I just thought "oh yeah, this would be a really interesting attack to try and I think it should work". So I tried it out and it ended up working out. Basically because I had researched quite a lot of how the application worked already.

PG: In real terms what are the implications of this research? I believe Flash is the most commonly installed piece of software on the planet because it ships with Windows, runs on Apple and Linux... It runs on absolutely everything... this is a cross platform bug isn’t it?

MD: Yes. Any system that has Flash installed. My exploitation methodology would work on a number of platforms with slight modification but it really depends on the specifics of each platform. My paper specifically targeted Windows but a similar style attack would likely to work out just fine on Mac and Linux etcetera.

PG: Work out just fine, I like that... Not if you're the owner of that machine! People are saying that this could mean that you have basically uncovered a separate class of vulnerability or made a particular class of vulnerability easier to exploit. Are they hyping this up to much or have you really opened up a bit of a can of worms with this stuff?

MD: Well time will tell I guess. I didn’t invent NULL pointer dereference bugs or anything like that. If you look in the past over the thousand of vulnerabilities that have come out over the past couple of years I am sure you will find a couple of instances of NULL dereference type bugs. In fact I even eluded to them in the book that I wrote several years ago. But one of the interesting things is that like we sort of mentioned before, very few developers and security researchers actually take the time to consider that they can be an exploitable bug rather than just breezing over it and either not noticing it or seeing it and going "yeah that is just a crash at best". From looking at other applications like since Flash I think that this kind of bug is more common than people think it is and people are going to start paying attention to those conditions a lot more carefully when they are doing code reviews and stuff like that.

PG: Do you think people are currently going back through old NULL pointer issues and trying to exploit them anew given the knowledge that’s surfaced in your paper?

MD: Yeah it is possible. Not just going back through old code but having it at the forefront of your mind when you are looking at new applications as well. Whenever you come across an allocation where the return value hasn’t been checked carefully, just looking at what happens immediately afterwards and seeing whether there is a situation where you can actually write to a valid location in memory and cause something very bad to happen.

PG: So we could see a flurry of pretty serious vulnerabilities pop up because of this research?

MD: Yes it is possible. It depends on how many people pick it up and run with it. Like I mentioned before I have found in other applications similar problems since then and they are in various stages of disclosure but my impression is that there is quite a few of these vulnerabilities to be found and it seems likely that over the rest of the year or however a lot more of these types of bugs are going to start surfacing.

PG: Yeah now one of the other things I read in various analysis pieces based on your paper is that this blows away the myth that code written in really high level languages like C# and so forth can’t have memory bugs. Can you walk us through the reasons why that is the case?

MD: A lot of the discussion is valid and some of it is misplaced. Basically the argument is that high level languages such as Java, C# and all that can’t have memory corruption style bugs because they basically don’t allow you to manipulate memory directly and that is true. But the thing they are glossing over is that the virtual machine itself is written in the lower level language in most cases and not only that but they have native extensions.

Basically when you need the virtual machine to actually do something with the underlying systems such as open files or get access to devices or whatever, there is often a native component underlying the virtual machine that has to communicate with and you end up having native code being executed in a whole series of circumstances to basically request things from the system.

To say that memory corruption bugs don’t exist in high level languages is not exactly true because you can find a vulnerability in the virtual machine itself or within one of these native extensions to the language. This is stuff that has been talked about before and if you look back over vulnerabilities in the past there have been vulnerabilities in the Java virtual machine as well as in dot net not so long ago. It is known that you can get access to low level vulnerabilities through these higher level languages but a lot of people sometimes tend to forget that.

PG: I suppose you have just reminded them with a vengeance. Congratulations again Mark. It seems like you have done very well out of this one and got the kudos from all the right people. What next are you working on? Can we warn people?

MD: I have got a couple of things lined up on my plate. At this stage I am probably going to be looking further into various protection mechanisms and stuff specifically on the Windows platforms, the Run Time protection mechanisms and stuff. I will probably be giving a talk on that kind of thing later in the year, maybe at Black Hat or something like that.

PG: So you are about to make some guys in Redmond very unhappy?

MD: They love it really!

PG: They like it rough!

MD: Yeah.

Read more on Application security and coding requirements