Liquid Staking
Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Merkle trees with leaf values longer than 64 bytes could be reinterpreted

angrymustacheman

Vulnerability Details

For the purpose of unqueuing & for claiming , Priority Pool uses Merkle trees to verify . To implement this verification process , PriorityPool.sol uses nodes/leaf which hashes more than 64 bytes using as can be seen here :
https://github.com/Cyfrin/2024-09-stakelink/blob/main/contracts/core/priorityPool/PriorityPool.sol#L343C13-L346C80

bytes32 node = keccak256(
bytes.concat(keccak256(abi.encode(account, _amount, _sharesAmount)))
);
if (!MerkleProofUpgradeable.verify(_merkleProof, merkleRoot, node))

but Openzeppelin's MerkleProofUpgradeable.sol library clearly gives the warning that usage of such node/leaf with more than 64 bytes length is not safe as those trees could be reinterpreted as a leaf value. as can be seen here -
https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/blob/v4.9.2/contracts/utils/cryptography/MerkleProofUpgradeable.sol#L13C1-L19C1

* WARNING: You should avoid using leaf values that are 64 bytes long prior to
* hashing, or use a hash function other than keccak256 for hashing leaves.
* This is because the concatenation of a sorted pair of internal nodes in
* the merkle tree could be reinterpreted as a leaf value.
* OpenZeppelin's JavaScript library generates merkle trees that are safe
* against this attack out of the box.
*/

Reference :
https://solodit.xyz/issues/m-5-merkle-leaf-values-for-_clubdivsmerkleroot-are-64-bytes-before-hashing-which-can-lead-to-merkle-tree-collisions-sherlock-none-footium-git

Recommendations

Use a combination of variables that doesn't sum to 64 bytes .

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.