_notSameBlock() can be circumvented in bondToAccount() #195
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Handle
gpersoon
Vulnerability details
Impact
The function bondToAccount() of Bonding.sol has a check based on _notSameBlock()
_notSameBlock() makes sure the same msg.sender cannot do 2 actions within the same block.
However this can be circumvented in this case:
Suppose you call bondToAccount() via a (custom) smart contract, then the msg.sender will be the address of the smart contract.
For a pseudo code proof of concept see below.
I'm not sure what the deeper reason is for the _notSameBlock() in bondToAccount().
But if it is important then circumventing this check it will pose a risk.
Proof of Concept
call function attack1.attack()
https://github.com/code-423n4/2021-11-malt/blob/d3f6a57ba6694b47389b16d9d0a36a956c5e6a94/src/contracts/Bonding.sol#L81-L92
https://github.com/code-423n4/2021-11-malt/blob/d3f6a57ba6694b47389b16d9d0a36a956c5e6a94/src/contracts/Permissions.sol#L135-L141
Tools Used
Recommended Mitigation Steps
Add access controls to the function bondToAccount()
An end-user could still call bond()
The text was updated successfully, but these errors were encountered: