2

really glad I found this great learning resource.

I was wondering, is there any way to fuzz or automate heap vulnerability assesment? I know a lot of practical frameworks for stack based fuzzing in its many variations, but when I read papers or cves, they note that they tried to find bugs by hand, making a program crash or avoid blue screen of death and debug it using windbg. But it is seems problematic to test for each function/vulnerability by hand, and it doesn't seem practical to go to the depth of each layer by hand.

Is there any smarter approach or known methods to scan/fuzz to heap vulnerabilites? if it matters, i prefer windows based frameworks, but linux on its many varieties is okay too.

Thank you very much for helping me and potentially a lot of other people as well who are interested on learning or expanding their vulnerability assessment skills.

| improve this question | | | | |
  • Do you have an example of a CVE where this is mentioned? If a heap-based bug produces a crash, I don't see why finding it with fuzzing would be any different from finding a stack-based bug. – multithr3at3d Mar 23 at 0:09
1

Great tool to achieve this in Windows is Application Verifier.

The general idea is that you run your program with different heap inspections, using the verifier. For example - each allocation made on a separate memory page, Freed memory is not just returned to the pool but marked as freed, and any later access to it will cause an excpetion and so on. This cost in significant memory costs, and some performance loss.

After enabling that, it's possible to use any fuzzing method, such as AFL.

Valgrind is a good equivalent for Linux.

| improve this answer | | | | |
  • These days I'd recommend AFL++ as the original author of AFL seems to have lost interest. Also, some fuzzing library exists in the scope of the LLVM project. Personally I find Valgrind rather slow compared to something instrumented with ASan. Of course Valgrind will also work on pure binary targets, though. Additionally DrMemory/DynamicRIO are worth a mention. – 0xC0000022L May 22 at 23:13
-1

Basically, when you limit the size of the PageHeap, it is easier to find bugs. If not taking into account things such as EMET or similar mitigations, basically, attach to windbg/IDA and try to see which functions are being called, why and what data you can overwrite or alter, either on purpose or as the result of something else.

Check the functions that are being called, for instance from a browser, and see if any allocations or overwrites are being done. If so, see how you can use them to your advantage to overwrite or allocate data to align your specific needs.

You can also use in memory or different fuzzing tools, but as a baseline, try to check how you mutate the data you insert and try to fuzz different elements of the acceptible protocol, let it be HTML, PHP,JAVASCRIPT,DOM,CSS and similar. Also try to check how the code is being handled by the browser, the way it's parsed and similarly.

A great amount of fuzzing guidelines rely on just crushing or overwriting some register, but that's only partial way to find bugs. Try to dig deeper, with a debugger attached and catch bugs that might not make a program crash or cause BSOD, but that are manageable, and see if they can help you control the flaw of the program.

If it's strictly regarding fuzzers, I'd also check if it's a dumb or a smart fuzzer, the way it mutates or generates input, what it looks for, if it understands protocols or just looks for crashes and similar.

| improve this answer | | | | |

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.