You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An attacker can deploy a malicious contract and have cargo contract verify incorrectly approve the malicious contract because the wasm code is not re-hashed.
Issue details
A file.contract that includes the correct source.hash field for a project but the incorrect source.wasm field will be validated by cargo contract verify --contract file.contract, even though it does not match the source code's output.
Steps to reproduce
An attacker could abuse this issue in the following way:
Write a contract.
Build the contract. This build will now be referred to as legit.contract.
Modify the contract to insert a backdoor or modify the logic.
Build the contract again. This build will now be referred to as malicious.contract.
At this point, the source.hash and source.wasm will be different for both files. The rest of the fields (aka the metadata) might be different, or not, but it does not matter in this issue.
Copy the source.hash field from legit.contract and paste it in malicious.contract's source.hash field.
Deploy the malicious.contract on a contract-enabled blockchain. This will work, as the hash field is not verified (and arguably shouldn't be) by the front-end and the chain.
Publish the source code (without the backdoor) along with malicious.contract as the build artifact (with a different name, otherwise they are a clumsy hacker).
An end-user's attempt at verifying this build artifact will be cargo contract verify --contract malicious.contract, which will approve malicious.contract because the source.hash matches the built wasm's hash.
Mitigation suggestion
cargo contract verify should re-hash the source.wasm field of a file.contract and verify that it matches the build hash and the source.hash field.
The text was updated successfully, but these errors were encountered:
Summary
An attacker can deploy a malicious contract and have
cargo contract verify
incorrectly approve the malicious contract because the wasm code is not re-hashed.Issue details
A
file.contract
that includes the correctsource.hash
field for a project but the incorrectsource.wasm
field will be validated bycargo contract verify --contract file.contract
, even though it does not match the source code's output.Steps to reproduce
An attacker could abuse this issue in the following way:
legit.contract
.malicious.contract
.At this point, the
source.hash
andsource.wasm
will be different for both files. The rest of the fields (aka the metadata) might be different, or not, but it does not matter in this issue.source.hash
field fromlegit.contract
and paste it inmalicious.contract
'ssource.hash
field.malicious.contract
on a contract-enabled blockchain. This will work, as the hash field is not verified (and arguably shouldn't be) by the front-end and the chain.malicious.contract
as the build artifact (with a different name, otherwise they are a clumsy hacker).An end-user's attempt at verifying this build artifact will be
cargo contract verify --contract malicious.contract
, which will approvemalicious.contract
because thesource.hash
matches the built wasm's hash.Mitigation suggestion
cargo contract verify
should re-hash thesource.wasm
field of afile.contract
and verify that it matches the build hash and thesource.hash
field.The text was updated successfully, but these errors were encountered: