Impact
Prior to 2.1.1 and 2.2.0, the Steel.validateCommitment Solidity library function will return true for a crafted commitment with a digest value of zero.
This violates the semantics of validateCommitment, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. Leveraging this bug to compromise the soundness of an application using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs (e.g. having the guest commit to a digest of zero, or failing to check the zkVM proof).
Because this bug does not risk application integrity, correctly written applications are not at risk.
Patches
Please see #605 for a full description of the bug, and the fix. This fix has been released as part of risc0-ethereum 2.1.1 and 2.2.0.
Recommended actions
Users for the Steel Solidity library versions 2.1.0 or earlier should ensure they are using Steel.validateCommitment in tandem with zkVM proof verification of a Steel program, as shown in the ERC-20 counter example, and documentation. This is the correct usage of Steel, and users following this pattern are not at risk, and do not need to take action.
Users not verifying a zkVM proof of a Steel program should update their application to do so, as this is incorrect usage of Steel.
Credit
A thank you to Daniel526 on HackenProof for reporting this issue
Impact
Prior to 2.1.1 and 2.2.0, the
Steel.validateCommitmentSolidity library function will returntruefor a crafted commitment with a digest value of zero.This violates the semantics of
validateCommitment, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. Leveraging this bug to compromise the soundness of an application using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs (e.g. having the guest commit to a digest of zero, or failing to check the zkVM proof).Because this bug does not risk application integrity, correctly written applications are not at risk.
Patches
Please see #605 for a full description of the bug, and the fix. This fix has been released as part of
risc0-ethereum2.1.1 and 2.2.0.Recommended actions
Users for the
SteelSolidity library versions 2.1.0 or earlier should ensure they are usingSteel.validateCommitmentin tandem with zkVM proof verification of a Steel program, as shown in the ERC-20 counter example, and documentation. This is the correct usage of Steel, and users following this pattern are not at risk, and do not need to take action.Users not verifying a zkVM proof of a Steel program should update their application to do so, as this is incorrect usage of Steel.
Credit
A thank you to Daniel526 on HackenProof for reporting this issue