Closed c4-bot-8 closed 4 months ago
Picodes marked the issue as duplicate of #59
Picodes marked the issue as selected for report
Out of scope per https://github.com/code-423n4/2024-01-salty-findings/issues/18
Picodes marked the issue as unsatisfactory: Out of scope
Lines of code
https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/ManagedWallet.sol#L59-L69
Vulnerability details
The
receive()
function is intended to accept Ether to confirm or reject wallet proposals. If 0.05 Ether or more is sent, it triggers a confirmation and starts a timelock. However, any Ether sent in excess of the 0.05 Ether threshold is not refunded to the sender.Impact
The confirmation wallet may send more than the required 0.05 Ether for confirmation, either by mistake or due to a lack of precision. The excess Ether is not returned, potentially resulting in an unintended loss of funds.
Proof of Concept
See the below code for confirming or rejecting wallet proposals by sending 0.05 ETH. But the below receiver function is not implemented any refund mechanism for excess transfer.
https://github.com/code-423n4/2024-01-salty/blob/53516c2cdfdfacb662cdea6417c52f23c94d5b5b/src/ManagedWallet.sol#L59C1-L69C10
Steps to Reproduce
proposeWallets
from themainWallet
with new wallet addresses.confirmationWallet
.Tools Used
Manual Review
Recommended Mitigation Steps
Introduce a refund mechanism within the
receive()
function to return any surplus Ether above the 0.05 Ether confirmation requirement.Suggested Fix
Assessed type
ETH-Transfer