Windbg Browser Fuzzing

TL;DR

This guide shows you how to use Windbg to find crashes in web browsers by sending them unexpected data (fuzzing). It’s a bit technical, but can help uncover security bugs.

Setting Up

1. Install WinDbg Preview: Download it from the Microsoft Store.
2. Symbols: Make sure you have symbol files for your browser and Windows. WinDbg will usually ask to download them automatically when needed, but you can configure this in Settings > Debugging Settings > Symbol Path. A good starting point is Microsoft’s documentation on symbol paths.
3. Browser: Choose the browser you want to test (Chrome, Firefox, Edge etc.). You’ll need a way to send data *to* it – often this is via HTTP requests or by manipulating its network traffic.

Fuzzing Process

1. Attach WinDbg: Start your browser. Then, in WinDbg, go to File > Attach to Process and select the browser’s process.
2. Set a Breakpoint (Optional): You can set breakpoints at interesting locations in the browser’s code. For example, you might want to break on memory allocation functions like malloc or string manipulation routines. Use

   bp kernel32!VirtualAlloc

   to set a breakpoint.

3. Generate Fuzz Data: This is where it gets creative. You need to create lots of different inputs for the browser. Some ideas:
   • Random Strings: Generate long, random strings and send them as URL parameters or form data.
   • Invalid HTML/JavaScript: Create malformed HTML or JavaScript code.
   • Large Files: Try uploading very large files.
   • Boundary Conditions: Test the limits of input fields (e.g., maximum length).
4. Send Data to Browser: Use a tool like Burp Suite, Postman, or write your own script to send the fuzz data to the browser.
5. Monitor for Crashes: WinDbg will stop if the browser crashes. If it does:
   • Examine the Crash Dump: Use commands like !analyze -v to get a detailed crash report. This will show you where the crash occurred and what caused it.
   • Stack Trace: Look at the stack trace (using k command) to see the sequence of function calls that led to the crash.
   • Registers: Check the values of registers (using r command) for clues about the input data.

Useful WinDbg Commands

• bp address: Set a breakpoint at a specific memory address.
• k: Display the call stack.
• r: Display registers.
• !analyze -v: Analyze the crash dump (provides detailed information).
• !process 0 0: Show process and thread information.
• dd address Lnumber: Dump memory at a specific address, showing number of bytes.

Example Scenario

Let’s say you suspect a buffer overflow in the browser’s handling of URL parameters.

1. Attach WinDbg to the browser process.
2. Set a breakpoint on a function that handles URL parsing (you’ll need to find this function through reverse engineering or debugging).
3. Send a very long string as a URL parameter: http://example.com/?param=A repeated many times.
4. If the browser crashes, WinDbg will stop at your breakpoint. Examine the stack trace and registers to see if the long string caused a buffer overflow.

Important Considerations

• Virtual Machines: Always fuzz in a virtual machine to protect your host system from crashes or malicious code.
• Reproducibility: Try to create a minimal test case that reliably reproduces the crash. This makes it easier to report the bug and for developers to fix it.
• Ethical Hacking: Only fuzz browsers you have permission to test.