BSidesSF 2018

### Overview In this BSidesSF 2018 presentation, Claudio Contini shares his research and methodology for fuzzing Ruby C extensions using American Fuzzy Lop (AFL). As a penetration tester with a web development background, Contini aimed to learn exploit development and vulnerability discovery by targeting native C extensions compiled into Ruby gems. Because C extensions operate closely with native memory management, vulnerabilities within them can lead to segmentation faults, memory corruption, and application server crashes in production Ruby applications.

### Key Topics - **Ruby C Extensions Architecture**: How gems use `extconf.rb` and C code via the Ruby API (`VALUE` pointers, Ruby header files) to improve performance or wrap legacy C libraries. - **Fuzzing Fundamentals & AFL**: Distinctions between dumb vs. smart fuzzing, mutation vs. generation-based approaches, and AFL's compile-time instrumentation and deferred/persistent modes. - **Fuzzing Setup**: Using Docker containers to compile AFL-instrumented Ruby binaries, skip Ruby initialization routines, and feed mutated inputs into simple Ruby harness scripts that invoke C extensions. - **Vulnerability Findings**: Case studies of discovered issues in popular gems including `ccsv`, `ox`, and `yajl-ruby`. - **Production Impact**: Demonstrating how native crashes in C extensions cause denial of service in Ruby application servers like Puma and Passenger, often leaving minimal or no diagnostic logs. - **Grammar-Based Fuzzing**: Addressing the limitations of mutation-based fuzzers when targeting language parsers using ANTLR and Grammarinator.

### Technical Details - **Fuzzing Pipeline**: Rather than writing complex C harness tests for each extension, Contini compiled the Ruby binary itself with AFL instrumentation (`afl-gcc`/`afl-clang`). He modified Ruby's `main.c` source code to use AFL deferred fork server mode, bypassing interpreter startup overhead. Simple Ruby scripts required the target C extension, ingested AFL's test input via `File.read`, and passed data directly into extension functions. - **Target 1 (`ccsv`)**: Within 20 seconds on a standard laptop, AFL triggered a crash. Root-cause analysis revealed a double-free vulnerability in the CSV parser occurring when handling backslash characters. Contini noted that unmitigated double-free bugs historically corrupt chunk pointers in `glibc` bins to gain arbitrary writes. - **Target 2 (`ox`)**: Fuzzing this XML parser uncovered a null pointer dereference within minutes, followed by a stack-based buffer overflow in the SAX parser where `strncpy` was invoked with an oversized length argument `n`. AFL with AddressSanitizer (ASan) confirmed the overflow. An off-by-one error was also identified and resolved with the maintainer. - **Target 3 (`yajl-ruby`)**: Fuzzing this C-based JSON parser triggered failed `assert` statements resulting in unexpected crashes, affecting a gem downloaded tens of millions of times. - **Server Behavior**: When tested in a Ruby on Rails environment, crashes in these extensions crashed worker processes. Puma did not log the crashes by default, making root-cause diagnosis difficult, whereas Passenger captured and logged process backtraces. - **Grammar-Based Fuzzing**: Because AFL produces syntactically invalid code when targeting the Ruby interpreter itself, Contini explored ANTLR grammars and Grammarinator (developed by Renáta Hodován) to generate syntactically valid Ruby test cases in Python 3.

### Takeaways Fuzzing does not require high-end hardware or extensive exploit development experience; meaningful bugs can be found using personal laptops and Docker containers. Organizations maintaining C code or Ruby C extensions should integrate continuous fuzzing alongside code reviews. Furthermore, because C extension segmentation faults crash application servers silently, production web servers must be monitored closely for native faults, and open-source platforms should support private vulnerability disclosure workflows.