Tuesday, March 10, 2009

Finding the Found

ARGH.

I wonder how often this happens to researchers. It's not that it has happened often to me, twice now, and once turned out to be slightly unique. I'm talking about finding a vulnerability that's not only been found before, but has also been fixed.

Yesterday I fulfilled a promise to myself, which I made long ago, to start looking at protocol handlers in *Nix. It took awhile... I was bored of them. Anyways, within minutes of starting on the newest install of Ubuntu, I discovered a format string flaw within the Vinagre VNC client's vnc:// protocol handler. It was basically your classic vnc://%n causes crash. I was thrilled, obviously, and set out to begin working on exploit code.

Then I came to the realization that I could make tracing this a lot easier if I looked at the source code first (tend to forget that exists when you do most your research on Windows). I searched Google for Vinagre's page, but one of the first hits that came up was to a Core Advisory on the very same format string flaw I had "found". DAMN! Forgot to update my fresh installed Ubuntu VMWare! DAMN! Found a flaw someone else already found and it's already fixed!

I guess it could've been worse, I could've spent forever working on exploit code and THEN found out. Kudos to the Core team for the find. Their advisory shows the p0c performed in a couple ways and they do mention that there's many ways to kick this off, but they don't mention the protocol handler (I wonder if the protocol handler was there by default when this was discovered). I do like the protocol handler attack vector... call me a web app guy if you must, but there's a perverse pleasure one takes in actually owning someone from a cross-site scripting attack (not just stealing some cookies).

I wonder how often this happens to other researchers... I mean, it could've been worse, I could've found the flaw, wrote the sploit, turned it in, only to have been undercut in the process by someone who didn't take the time to fully explore the flaw.

Oh well, one down, several to go when it comes to the *Nix protocol handler front... although, I did like the idea of finding an exploit in one that was there by default.

Interesting side note... I mentioned this happened to me one other time as well, but that it turned out to be a unique case. This was actually in the format string flaw that I found in Apple's iPhoto, which was originally reported and "fixed" with the Month of Apple Bugs project. I remember very well contacting Erik Cabetas for some assistance in putting out some proof of concept exploit code and him telling me that it had already been found during MOAB and fixed by Apple.

I was blown away since I had literally just bought and patched my Mac Book. At the time, I was brute force trying to hit up protocol handlers on the Mac for fodder for my "URI Use and Abuse" research and was attempting to use a string designed to cause either a format string flaw or some kind of buffer overflow. The string I had used was a long string of %n characters... or so I thought. Apparently in the process of creating that long string, I accidentally had typed a %dd into the mix. This pushed iPhoto down a different path, leading to the same vulnerability in a different code path.

Let no one speak ill of my poor typing skillz again :).

7 comments:

kuza55 said...

Yeah, it's happened a few times, though not with non-updated software, just techniques/ideas that others had already mentioned; the most memorable was rediscovering XSS via non-http services which Wade Alcorn wrote his "Inter-protocol communication" paper about.

In these cases I end up feel kinda stupid and disappointed.

But that's kinda ok, what sucks is when you're getting ready to drop a bug or something so you can whore it up at some conference and then you see that someone already reported it and a patch is being released 2 weeks before the conf...

In these cases I just rage, since there's nothing I could have done to prevent it other than drop sooner, lol >_<

kuza55 said...

On a related note: software (especially browsers!) is secure, everyone else should stop looking for bugs, etc :p

pdp said...

It is even worse when you start doing some awesome research when you find out that someone has already done the job for you long ago but his/her paper was well obscured in the depths of the Internet.

Yes, it happens all the time. And people often get annoyed for not being credited but this is how the life is. Mistakes happen... sometimes unintentionally.

At some point I was even thinking to create some kind of research register to eliminate the possibility for doing the same research twice. Than I thought of packetstorm and milw0rm. The registers had already existed. :) falling into the trap again!

Nate McFeters said...

Hahaha @kuza55 "... what sucks is when you're getting ready to drop a bug or something so you can whore it up at some conference and then you see that someone already reported it and a patch is being released 2 weeks before the conf...

In these cases I just rage..."

Hahaha, too funy man, but too true. I suppose t serves the media whore in us right. :)

And yeah, I agree, software is safe everyone, stop wasting your time testing it :).

Nate McFeters said...

@pdp haha on the
milw0rm/packetstorm thing.

Aaron Grattafiori said...

I've had this happen quite a few times, with vulnerabilities and research. Also a few times I've been at a talk @DefCon and written down some idea.... Then started hashing out the details only to see that someone else is presenting on that @Toorcon. Oh well, cheers to all the guys who get there first.

CurtW said...

I found a scenario where an SSH client was caching passwords in memory even after the connection was closed. I was preparing to figure out if there was a predictable offset for this and make a little dumper app (intended to call it sillyputty.exe) and then I found out that someone had already made a few hundred bucks on the bug with idefense.