Should I configure my OS in any particular way, if I'm going to be doing some fuzz testing? Should I turn off ASLR (address space randomization)? Does it matter?

  • Are you evaluating the robustness of the OS or something else? – this.josh Sep 9 '11 at 7:59
  • Oops, sorry about the ambiguity, @this.josh! I'm evaluating an ordinary user-mode software application. Many OS's have security settings that can be configured. Does it matter how I configure the OS that is running the fuzzing environment? For instance, will enabling security settings help my fuzzer detect more bugs? – D.W. Sep 9 '11 at 16:46

I recommend using a fuzzing framework that has a testing harness like the one foudn in Peach Fuzz. A testing harness will attach a debugger to your target application and keep track of crash reports and what fuzz test case caused it. When the target application crashes, the harness will restart the application and continue testing.

ASLR,NX zones, Canaries, heap cookies, ect, ect, ect, will not cause problems with the fuzzing process. However these will make it very difficult to exploit the memory corruption vulnerability when you find it.


ASLR is a broad term that encompases many different protections and techniques. In general, basic forms of ASLR (eg stack randomisation) are used to make development of exploits harder or impossible - but do not prevent the triggering of the bug and a crash of an application. Fuzzing should work the same with aslr enabled or not.

  • 1
    I just figured that by mistake I was referring to GCC's SSP, not PIE, when talking about variable reordering, sorry about that. To answer your question, some bugs are there because of compiler specifics, not from the actual application code itself. To detect these bugs you should fuzz with the settings the application is shipped with, and aslr shouldn't matter (but SSP would) – john Sep 9 '11 at 17:08

Off the top of my head, I don't think aslr will matter much one way or the other - it seems to me that it's more effective at preventing a bug from turning into a vuln. Anytime your fuzzer gets an out-of-range result, you're safest assuming it can be used against you; not sure aslr would change that since there are plenty of ways of getting around it (depending on settings, platform, yada yada).

Anyway, I'd say you should make the system as loose as possible to give your fuzzer the max chance of successfully finding holes - no firewall, high ulimits, plenty of bandwidth, lots of processors if you're on a multithreaded app to maximize the chance of race conditions, etc.

I'd also recommend fuzzing while running on more than one OS, since libraries may behave differently. That particularly goes for Windows, which has lots of good debugging stuff. Don't know much about osx, but if you can get your stuff running there, you're likely to find a substantially different environment.

Please post results - I'm curious to know how this works out.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.