Getting More Confident with Your Security Helper Libraries Thanks to Go Fuzzing

Using Go Fuzzing to improve the test coverage of security helper libraries and gain confidence in their effectiveness

• Security helper libraries can be hard to unit test as they need to ensure 'bad' inputs are not considered valid
• Go Fuzzing can be used to identify corner cases and improve test coverage
• A real-life example of a path traversal vulnerability in Grafana OSS is used to demonstrate the effectiveness of Go Fuzzing
• Writing predicates for Go Fuzzing can be challenging as the validation logic becomes more complex
• Once trusted security helpers are identified, they should be communicated and enforced through static analysis tools

The speaker shares a real-life example of a path traversal vulnerability in Grafana OSS that was actively exploited as a zero-day. The vulnerability was fixed, but it highlighted the complexity of the method 'filepath.Clean' and the need for better testing of security helper libraries. Go Fuzzing was used to improve the test coverage and identify corner cases that were not obvious. This helped to gain confidence in the effectiveness of the security fix and identify potential bypasses.

Security helper libraries are often hard to unit test because they should make sure “bad” inputs are not considered valid, but how can we know we are not forgetting one kind of “bad” input? In cases where we don’t have an explicit definition of a good input, Go Fuzzing can be really helpful to gain confidence we are not missing some corner cases. Using a real-life example of a path traversal vulnerability in Grafana OSS, this talk will show how Go Fuzzing can be used to improve the test coverage of the corresponding security fix. Additionally, it will cover how this technique helped validate more complex security helpers and enabled us to detect some bypasses.