Closed c4-bot-4 closed 10 months ago
raymondfam marked the issue as insufficient quality report
raymondfam marked the issue as duplicate of #142
0xA5DF marked the issue as selected for report
0xA5DF marked issue #142 as primary and marked this issue as a duplicate of 142
0xA5DF marked the issue as not a duplicate
0xA5DF marked the issue as unsatisfactory: Invalid
But this only works if the previous interaction has set this value before the next interaction gets it.
Seems like intended design
Lines of code
https://github.com/code-423n4/2023-11-shellprotocol/blob/485de7383cdf88284ee6bcf2926fb7c19e9fb257/src/ocean/Ocean.sol#L514-L519
Vulnerability details
When the user specifies a interaction he/she can set
specifiedAmount
to max in the intention to get the amount of desired token into account for un/wraping.But this only works if the previous interaction has set this value before the next interaction gets it.
There can be a situation that will be describe in the POC when this doesn't work correctly.
Impact
The user cannot always relay on specifying
specifiedAmount
value to max to get the right amount.Proof of Concept
The following POC will demonstrate what happens when the user tries to get/unwrap the output token in two separate interactions:
// First interaction
// Second interaction
specifiedAmount
to max but it fails and the token remain inside the ocean contractTools Used
forge of foundry
Recommended Mitigation Steps
By modifying the method
_doMultipleInteractions
inside theocean
contract we can check the balance from the contract and adjust its decimals to get the correctbalanceDelta
amount :From
https://github.com/code-423n4/2023-11-shellprotocol/blob/485de7383cdf88284ee6bcf2926fb7c19e9fb257/src/ocean/Ocean.sol#L514-L519
to
Also add the following line to the
OceanAdapter
abstract contract to help the code differentiate between adapters and tokens.When we rerun the previous test we get:
Assessed type
Token-Transfer