OpenRCE Blog Entry

Justin Seitz (jms) <jms

bughunter

ca>

Wednesday, May 2 2007 22:07.18 CDT

Well this may not be directly RE related, but I thought it might make an interesting blog posting. I recently came upon an interesting bug, and by interesting I mean I could NOT for the life of me reproduce it in any way!

The bug was inside a certain server daemon, and my fuzzer would hit the bug after about 4000 iterations. Fine and dandy. Now the tricky part was capturing what magic packet finally did the trick (Wireshark does NOT like to run for hours on end :) and since changing my fuzzer to replay everything it did at what time would take heavy code modidifications, which I didn't wanna do, I was somewhat stuck.

I reduced this to doing 1000 iterations at a time when I could monitor it, and finally got it to the point where I had found the spot where the crash occurred. Paydirt!

Not so fast, when I took this beauty of a packet capture, converted everything over to Python....it didn't work. I tried cat | nc target port ....no love. After some prodding a good friend of mine finally convinced me to get an active netcat session with the server, and send the commands one after the other, and sure enough it worked.

I had learned the valuable lesson on timing! Especially when you use fuzzing tools like GPF (www.appliedsec.com), which is intelligent enough to handle timing when doing network read/writes, in order for you to reproduce this in your code you gotta throw a couple of sleep()'s in there.

I know this probably isn't the most helpful posting to any of you, but it really made me think about all those times that I had been stalking something in PaiMei and ran an automated fuzzer, came back to find it had crashed the process but I could never reproduce.....if only I could have been patient, I wonder how many of those would have turned into exploitable bugs?

Glich	Posted: Thursday, May 3 2007 11:33.51 CDT
Couldn't you have attached a debugger from the fuzzer so that it would break on exception and record the packet? - Glich

jms

Posted: Thursday, May 3 2007 16:07.11 CDT

Well of course I had a debugger attached (or I wouldn't be able to tell the application crashed), and yes recording the packet is fine. But...with ~4000 iterations, the challenge was capturing the _right_ packet.

After that, the timing issue was the problem :) I should have mentioned that whenever you are doing multi-stage exploit dev on a server (say a post-auth bug in a FTP server), ensure you are reading back what the server is sending so that you know when to fire back at it.

jms	Posted: Thursday, May 3 2007 16:08.43 CDT
As well, as I might not have correctly answered your question, yes I could have mangled the fuzzer to get what I needed in order to record the last sent packet, but the particular fuzzer I was working with did not easily lend itself to doing that. PaiMei definitely leaves some room for us to think about how to solve this problem, so that we can use _any_ fuzzer without modification.