Why the Fuzz About Fuzzing Compilers?

Compilers, especially those designed for the evolving world of blockchain technology, play a critical role where innovative techniques meet the necessity for reliability. And in an age when languages progress as fast as the compilers and hardware they run on, having robust testing methodologies should be a priority.

Fuzzing for Blockchain Compilers: An Uncharted Territory

The exploration of fuzzers within the blockchain compiler sphere remains largely untapped, presenting a fertile ground for pioneering work. With the increasing complexity of Virtual Machines (VMs) and the advent of innovative propositions like WASM VMs, the application of state-of-the-art (SotA) testing techniques to compilers is essential. These preventive measures are priceless in any ecosystem where the fixing of poorly deployed or harmful code is expensive and complicated.

Case Study: The Clarity Compiler

The Clarity compiler, processes the Clarity smart contract language, translating its Abstract Syntax Tree (AST) directly into WebAssembly (WebASM), bypassing optimization passes for a straightforward translation. For further details on Claritys language specifics, refer to the Clarity documentation.

Elevating Fuzzer Efficiency

Zest stands out by embracing structure-aware fuzzing, crucial for generating highly structured inputs programs in this context. Focusing beyond parser errors, Zest ensures inputs are syntactically valid, with a high likelihood of semantic validity. Leveraging coverage-guided fuzzing, it retains inputs that unveil new coverage patterns, forming a corpus for subsequent mutations. Semantic validity feedback is integrated, enhancing Zests discernment in result evaluation. Utilizing libfuzzer for byte stream generation, Zest employs a Clarity generator to deterministically convert these streams into syntactically and semantically valid Clarity programs, filtering out predictable errors like type mismatches.

Our Solution: Architectural Insights and Coverage Reporting

Schematic view of our mutation-based fuzzing strategy.

We devised a Clarity code generator that accepts a random byte string and outputs valid Clarity programs. Despite its initial iteration having a limited set of opcodes and language features, it proved effective in uncovering noteworthy findings. Utilizing Rusts implementation of LibFuzzer, we managed the byte string generation, corpus handling, and coverage information retrieval.

Post-run, we meticulously analyzed the compilers output, filtering trivial findings and employing a WASM parser check to ensure the generated WASMs validity in successful compilation cases.

Findings and Insights

The compiler allows you to name variables/functions with type names. This means that from there on in the contract, the type name is replaced by the name of the variable/function. There might be attack vectors that could exploit this.
The compiler does not appear to limit the number of locals that the resulting WASM generates. It seems that the garbage lines of literals (e.g., declaring a bare integer that is not used at all and is functionally equivalent to a nop) generate locals in the WASM. This is particularly insidious with lists. So a bloated program might compile without problems, but when validating them with a WASM parser, it warns that the use of locals is being exceeded.

Looking Ahead: Enhancements and Future Fuzzers

Our journey doesnt end here. We envision extending the Clarity compilers capabilities, exploring additional fuzzing strategies, and delving deeper into the nuances of Stacks.

As we continue to unravel the complexities of blockchain compilers, we invite the community to join us in this pioneering endeavor. Together, we can enhance the robustness and reliability of blockchain technologies, paving the way for a more secure future.

The Entry Why the Fuzz About Fuzzing Compilers? was published first on CoinFabrik.

Text source: CoinFabrik Blog

Blog