BLOCKHASH Opcode does not comply with Kakarot spec #130
Labels
bug
Something isn't working
downgraded by judge
Judge downgraded the risk level of this issue
duplicate-5
edited-by-warden
grade-b
Q-01
QA (Quality Assurance)
Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
🤖_21_group
AI based duplicate group recommendation
satisfactory
satisfies C4 submission criteria; eligible for awards
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
sufficient quality report
This report is of sufficient quality
Lines of code
https://github.com/kkrt-labs/kakarot/blob/697100af34444b3931c18596cec56c454caf28ed/src/kakarot/instructions/block_information.cairo#L167-L172
Vulnerability details
Proof of Concept
blockhash
function in theInternals
namespace does not align with the Kakarot protocol's hint for the BLOCKHASH opcode. According to the Kakarot's doc, the BLOCKHASH opcode should return 0 for the last 10 blocks, but this is not followed.https://github.com/kkrt-labs/kakarot/blob/697100af34444b3931c18596cec56c454caf28ed/src/kakarot/instructions/block_information.cairo#L167-L172
This allows access to block hashes for all blocks within the last 256 blocks, including the most recent ones. It does not implement the Kakarot-specific behavior of returning 0 for the last 10 blocks.
Reference to Kakarot's doc:
This could cause issues for contracts expecting Kakarot's specified BLOCKHASH behavior.
Recommended Mitigation Steps
Modify the
blockhash
function to comply with Kakarot's specification:Assessed type
Other
The text was updated successfully, but these errors were encountered: