Beacon Fuzz - Progress Update #5
Beacon Fuzz - Update #05
Sigma Prime is leading the development and maintenance of beacon-fuzz, a differential fuzzing solution for Eth2 clients. This post is part of our series of status updates where we discuss current progress, interesting challenges encountered and direction for future work. See #00 and the repository's README for more context.
Summary
- Prysm client integration and first bugs
- Lodestar integration and first bugs
- Lighthouse ENR crate bug
- Dockerising Eth2fuzz
- Next Steps
Prysm Integration
As mentioned in our previous updates, one of the biggest challenges faced while working on Beacon Fuzz was the integration of the Prysm client alongside ZRNT, protolambda's Go executable Eth2 specification. The issues encountered by the team were documented extensively in our previous posts (#1, #2, #4).
Recently, Prysmatic Labs announced their "biggest feature of the year", which allows developers to build the Prysm client using the native go build
functionality, without the need of using Bazel
. As mentioned by Preston in the related pull request, this removes a lot of friction for external contributors and developers wanting to integrate/build on top off the Eth2 Golang implementation. We requested this feature in this issue and were very happy to see it implemented, a big thank you to the Prysmatic Labs crew!
As a result, significant progress has been made in fuzzing Prysm (progress can be tracked in this branch) which yielded the identification of the following vulnerabilities:
- Panic due to an out-of-bands slice range: identified in in the
go-ssz
library, while fuzzingAttestation
parsing. Refer to this issue for the detailed bug report and this pull request for the related fix. - Panic due to a nil pointer dereference: identified in
ProposerSlashing
processing while fuzzing theVerifyProposerSlashing
function. Refer to this issue for the detailed bug report and this pull request for the related fix.
Lodestar Integration
A new Eth2 implementation has made it to Beacon Fuzz! We're glad to have been able to perform some fuzzing on Lodestar
, the JavaScript client developed by ChainSafe. We've been primarily targeting serialisation/deserialisation functions by leveraging jsfuzz
, a coverage guided fuzzer for JS/NodeJS packages, heavily based on go-fuzz
and AFL
.
The first Lodestar fuzzing round lead to the identification of the four following bugs:
TypeError
bug when SSZ decoding aBeaconBlock
with an invalidBigInt
parent scope (refer to this issue for more details);RangeError
bug when SSZ decoding an emptyBeaconBlock
container (refer to this issue for more details);TypeError
bug when decoding an invalid base64ENR
string (refer to this issue for more details);TypeError
bug when decoding an invalidENR
RLP
encoded string (refer to this issue for more details).
We're looking forward to targeting the state transition functions next, when these bugs are resolved by the Lodestar development team.
Lighthouse ENR Crate Bug
While fuzzing the Lighthouse ENR crate, we identified a vulnerability that can be exploited when a non-utf8 string is attempted to be decoded as an ENR.
Specifically, Honggfuzz, the fuzzing engine used to identify this vulnerability, produced the string 49ลท
that caused a panic in the related crate. This bug is reproducible here.
This vulnerability was fixed by Age in this pull request.
Dockerising Eth2fuzz
We're currently in the process of dockerising our fuzzers to enable the community to participate in identifying bugs across the Eth2 implementations. Since each fuzzing instance uses a random seed, the more people run these fuzzers, the more chances we have to uncover bugs and vulnerabilities. We've been running our fuzzers on our local infrastructure and are exploring integrated, continuous fuzzing options (see section below), but would love to see these fuzzers running on other machines. We were hoping to have the dockerisation process ready for this blog post, but have been running into the following issues:
- Compilation time and resulting disk space is currently quite prohibitive (we're targeting initial support for 3 to 4 different implementations);
- Race conditions currently prevent running different fuzzing engines on different implementations simultaneously;
- An obscure bug affecting
jsfuzz
preventing us from fuzzing the Lodestar when using containers.
We're hoping to have these resolved imminently and to start working on easy-to-follow instructions for the community to participate in the Eth2 fuzzing effort. Stay tuned for an exciting announcement over the coming days!
Next Steps
Over the next few weeks, the Beacon Fuzz team will be looking into:
- Finalising the dockerisation process
- Fuzzing the p2p networking stack of the Eth2 clients
- Working on the FFI bindings to complete the revamp in Rust
- Start deploying our work to continuous fuzzing environments (OSS Fuzz)