Fuzzing Lua in OSS-Fuzz
Open source projects written in Lua language can add their project to OSS-Fuzz by following documentation.
The Google Open Source Security team helped to integrate luzer library with OSS-Fuzz. Thanks to their support and help with integration, open source projects written in Lua language can now use OSS-Fuzz for continuous fuzzing.
OSS-Fuzz has found more than 50,000 bugs in open source projects using fuzzing. I’m looking forward to seeing how this technique can help secure and improve code written in Lua language and code written in C/C++ language with Lua API.
What can luzer do?
luzer allows users to fuzz code
written in Lua language with libFuzzer,
as they already can for code written in C/C++. It does this by providing code
coverage feedback from hook mechanism of the debug library in Lua to libFuzzer. luzer
already supports important libFuzzer features such as:
- FuzzedDataProvider for fuzzing code that doesn’t accept raw bytes, FDP turning the raw input bytes into Lua primitive types.
- Evaluation of code coverage based on 8-bit edge counters.
- Minimization of crashing inputs.
The intent for luzer is to support all libFuzzer features eventually.
What Does luzer Support?
luzer supports all languages that transpile to Lua, since instrumentation is done on the source code level. This includes:
luzer can also provide coverage feedback from native code that is executed through Lua C API. This can uncover interesting memory corruption vulnerabilities in memory unsafe native code.
Why Fuzz Lua Projects?
As I explained in OSS Fuzz issue and pull request, fuzzing code written in memory safe languages, such as Lua language, is useful for finding bugs where code behaves incorrectly or crashes. Incorrect behavior can be just as dangerous as memory corruption. For example, luzer was used to find issues in msgpack library (tarantool/tarantool#7818, tarantool/tarantool#10360, tarantool/tarantool#10361). Bugs causing crashes or incorrect exceptions can sometimes be used for denial of service.
When fuzzing memory safe code, you can use the same classic approach for
fuzzing memory unsafe code: passing mutated input to code and waiting for
crashes. Or you can take a more unit test like approach where your fuzzer
verifies that the code is behaving correctly and invariants are succeed
on all generated inputs. luzer was succeed on testing datetime module
in Tarantool, where it found issues in correctness:
tarantool/tarantool#7144,
tarantool/tarantool#7145,
tarantool/tarantool#6882.
Another way fuzzing can find interesting bugs in Lua code is through differential fuzzing. With differential fuzzing, your fuzzer passes mutated input from the fuzzer to multiple library implementations that should have the same functionality. Then it compares the results from each library to find differences. In Tarantool we use differential testing for Lua runtimes: complicated LuaJIT compiler should behave in the same way as a less sophisticated PUC Rio Lua virtual machine.
Check out luzer documentation to get started.