Closed code423n4 closed 11 months ago
0xSorryNotSorry marked the issue as primary issue
this is out of scope per contest rules https://github.com/code-423n4/2023-07-moonwell/blob/4aaa7d6767da3bc42e31c18ea2e75736a4ea53d4/README.md
ElliotFriedman marked the issue as sponsor disputed
Out of scope
alcueca marked the issue as unsatisfactory: Invalid
Lines of code
https://github.com/code-423n4/2023-07-moonwell/blob/main/src/core/Governance/Well.sol#L113-L132 https://github.com/code-423n4/2023-07-moonwell/blob/main/src/core/Governance/Well.sol#L195-L204
Vulnerability details
Impact
The
ecrecover
function is an inherent cryptographic function within Solidity which enables the retrieval of the signer's address messages which have been signed with their private key. Of course, this is very important when it comes to verifying the authenticity of a message from a cryptographic standpoint. The team did not implement ECDSA correctly withinWell.sol
pertaining to thepermit
anddelegateBySig
functions, because the values ofs
andv
are not sanitised. The curve is fundamentally symmetrical on the x-axis and therefore permits signatures to be replayed with the samex
value (in this instancer
) but a differenty
value (in this instances
).Proof of Concept
Imagine
userA
signs a transaction with their public key. The transaction is included within the blockchain and a miner eventually picks it up. Among all of the transactions that are awaiting to be successful, there isuserB
whom is malicious, and has the intention of executing transaction malleability againstuserA
or, for this matter, any user who is interacting with the protocol.userB
will retrieve the values ofv
,r
, ands
foruserA
and replay the transaction with the same signature by simply tweaking thes
value and maintaining the samer
value which was used foruserA
.https://github.com/code-423n4/2023-07-moonwell/blob/main/src/core/Governance/Well.sol#L113-L132
https://github.com/code-423n4/2023-07-moonwell/blob/main/src/core/Governance/Well.sol#L195-L204
Tools Used
Manual review
Recommended Mitigation Steps
Ideally,
v
has to be checked so that it is equal to27
or28
, ands
has to be ensured that it is within the lower half order of the elliptic curve, so that it is less than0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A1
.You can also utilise OpenZeppelin's default ECDSA library: https://github.com/OpenZeppelin/openzeppelin-sdk/blob/master/packages/lib/contracts/cryptography/ECDSA.sol
I would also like to add into reference the exact same bug present on a project named Platypus Finance Governance Staking (dated 9 Apr 2022) which was audited by Omniscia: https://omniscia.io/platypus-finance-governance-staking/manual-review/Ptp-PTP
Further references:
Assessed type
Invalid Validation