Earlier this year, we launched a bug bounty program focused on finding issues in the beacon chain specification, and/or in client implementations (Lighthouse, Nimbus, Teku, Prysm etc...). The results (and vulnerability reports) have been enlightening as have the lessons learned while patching potential issues.
In this new series, we aim to explore and share some of the insight we've gained from security work to date and as we move forward.
This first post will analyze some of the submissions specifically targeting BLS primitives.
Disclaimer: All bugs mentioned in this post have been already fixed.
BLS is everywhere
A few years ago, Diego F. Aranha gave a talk at the 21st Workshop on Elliptic Curve Cryptography with the title: Pairings are not dead, just resting. How prophetic.
Here we are in 2021, and pairings are one of the primary actors behind many of the cryptographic primitives used in the blockchain space (and beyond): BLS aggregate signatures, ZK-SNARKS systems, etc.
Development and standardization work related to BLS signatures has been an ongoing project for EF researchers for a while now, driven in-part by Justin Drake and summarized in a recent post of his on reddit.
The latest and greatest
In the meantime, there have been plenty of updates. BLS12-381 is now universally recognized as the pairing curve to be used given our present knowledge.
Three different IRTF drafts are currently under development:
Moreover, the beacon chain specification has matured and is already partially deployed. As mentioned above, BLS signatures are an important piece of the puzzle behind proof-of-stake (PoS) and the beacon chain.
Recent lessons learned
After collecting submissions targeting the BLS primitives used in the consensus-layer, we're able to split reported bugs into three areas:
- IRTF draft oversights
- Implementation mistakes
- IRTF draft implementation violations
Let's zoom into each section.
IRTF draft oversights
One of the reporters, (Nguyen Thoi Minh Quan), found discrepancies in the IRTF draft, and published two white papers with findings:
While the specific inconsistencies are still subject for debate, he found some interesting implementation issues while conducting his research.
Implementation mistakes
Guido Vranken was able to uncover several "little" issues in BLST using differential fuzzing. See examples of those below:
- blst: Inverse modulo hangs on i386 if input is 0 or multiple of modulo
- blst: Using non-standard 'dst' parameter branches on uninitialized memory
He topped this off with discovery of a moderate vulnerability affecting the BLST's blst_fp_eucl_inverse function.
IRTF draft implementation violations
A third category of bug was related to IRTF draft implementation violations. The first one affected the Prysm client.
In order to describe this we need first to provide a bit of background. The BLS signatures IRTF draft includes 3 schemes:
- Basic scheme
- Message augmentation
- Proof of possession
The Prysm client doesn't make any distinction between the 3 in its API, which is unique among implementations (e.g. py_ecc). One peculiarity about the basic scheme is quoting verbatim: 'This function first ensures that all messages are distinct' . This was not ensured in the AggregateVerify function. Prysm fixed this discrepancy by deprecating the usage of AggregateVerify (which is not used anywhere in the beacon chain specification).
A second issue impacted py_ecc. In this case, the serialization process described in the ZCash BLS12-381 specification that stores integers are always within the range of [0, p - 1]. The py_ecc implementation did this check for the G2 group of BLS12-381 only for the real part but did not perform the modulus operation for the imaginary part. The issue was fixed with the following pull request: Insufficient Validation on decompress_G2 Deserialization in py_ecc.
Wrapping up
Today, we took a look at the BLS related reports we have received as part of our bug bounty program, but this is definitely not the end of the story for security work or for adventures related to BLS.
We strongly encourage you to help ensure the consensus-layer continues to grow safer over time. With that, we look forward hearing from you and encourage you to DIG! If you think you've found a security vulnerability or any bug related to the beacon chain or related clients, submit a bug report! 💜🦄