Closed c4-submissions closed 11 months ago
raymondfam marked the issue as primary issue
raymondfam marked the issue as sufficient quality report
FJ-Riveros (sponsor) disputed
fatherGoose1 marked the issue as unsatisfactory: Invalid
Intended design.
Lines of code
https://github.com/code-423n4/2023-10-ethena/blob/ee67d9b542642c9757a6b826c82d0cae60256509/contracts/EthenaMinting.sol#L175-L178 https://github.com/code-423n4/2023-10-ethena/blob/ee67d9b542642c9757a6b826c82d0cae60256509/contracts/EthenaMinting.sol#L206-L207
Vulnerability details
Impact
Users will retain possession of their
USDe
after redeeming their collateral this can lead to theft/loss of funds.Proof of Concept
See belo for the coded POC.
The
benefactor
and thebeneficiary
in theOrder
struct containing order details and confirmation from server, are addresses controlled by the same user. The vulnerability lies in the fact that when theminter
calls mint, the collateral is transferred from theorder.benefactor
to theroute.addresses
in theratios
provided and thenUSDe
is minted to theorder.beneficiary
as shown belowHowever, when the
redeemer
callsredeem(...)
, the function burnsUSDe
from theorder.benefactor
(who has noUSDe
to burn from) and transfers the collateral to theorder.beneficiary
. And so theorder.beneficiary
is holding both the collateral asset and theUSDe
asPOC
Add the test case to the
EthernaMinting.core.t.sol
and runforge test --mt testMintWithoutCollateral -vv
Tools Used
Foundry
Recommended Mitigation Steps
redeem function check the balance of
USDeand
collateralAssetin both the
order.beneficiaryand the
order.benefactor``` addresses before attmpting a burn or transfer.Assessed type
Other