Closed c4-bot-8 closed 8 months ago
raymondfam marked the issue as sufficient quality report
raymondfam marked the issue as duplicate of #41
Expiry manipulation with coded POC.
raymondfam marked the issue as not a duplicate
raymondfam marked the issue as primary issue
Expiry manipulation with coded POC.
raymondfam marked the issue as high quality report
malicious dapps need only present such nonstandard WithdrawRequests for unsuspecting users to sign, effectively granting dapps the right to deny UserOperations containing WithdrawRequests in the paymasterAndData field.
Will review further, but users do not sing WithdrawRequests.
wilsoncusack marked the issue as disagree with severity
wilsoncusack (sponsor) acknowledged
I am not sure that I fully understand this report. If we boil it down to the essential, we have:
I don't see any impact with this nor any DoS other than the attack itself reverting (as shown in the PoC).
The warden is invited to provide more details if they participate to the upcoming QA session.
3docSec marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2024-03-coinbase/blob/e0573369b865d47fed778de00a7b6df65ab1744e/src/MagicSpend/MagicSpend.sol#L114
Vulnerability details
Impact
Maliciously constructed WithdrawRequest calldata structs (for example reordered or constructed by bad frontend) can manipulate
expiry
value decoding to DOS all MagicSpend WithdrawRequests from a signer.Manually restructured WithdrawRequest calldata (using nonstandard ABI encoding) which is formatted to fit a EIP2098 compact signature can derive and then pack a full 65 byte signature into the same struct without altering its hash. This is achieved by using the big endian side of the
expiry
slot to store theuint8 v
yParity and arises due to malleability of ABI encoding as well as MagicSpend's lack of enforcement and validation for the struct's encoding.Since a full 65 byte signature can be obtained from a compact EIP2098 (and vice versa), malicious dapps need only present such nonstandard WithdrawRequests for unsuspecting users to sign, effectively granting dapps the right to deny UserOperations containing WithdrawRequests in the
paymasterAndData
field. When structured as shown in the PoC,expiry
is tricked to return the length of the signature (64 or 65) as opposed to a relevantblock.timestamp
in Unix format. This means the signature expired in 1972 and is completely unusable.Proof of Concept
The following test file is designed for integration with the audit repository by being placed in a new "PoC" or other name dir within
2024-03-coinbase/test/SmartWallet/
and then run to observe the attack:For clarity, the following is a malicious yet valid nonstandard ABI-encoded WithdrawRequest:
Tools Used
Manual review
Recommended Mitigation Steps
Mitigation can be achieved in multiple ways, namely:
Assessed type
DoS