OpenRCE

📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Created: Wednesday, May 2 2007 22:07.18 CDT

Modified: Wednesday, May 2 2007 22:09.49 CDT

Printer Friendly ...

Timing: The Bane of My Fuzzing Existence

Author: jms

# Views: 1955

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?

Blog Comments

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.

There are 31,328 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06
Question about memor...	Dec/12

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit