You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2024. It is now read-only.
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
Wrong Sablier contract is being called in _retrieve()
Summary
When _retrieve() is called we first call the PRBProxy which delegate calls a Sablier ProxyTarget which then calls the Sablier lockup. the problem here is that the wrong _target address is being used to call withdrawMax()
Vulnerability Detail
To withdraw from the Sablier stream we first need to call the PRBProxy which is the recipient of the stream, this proxy will then delegate call SablierV2ProxyTarget which will then call withdrawMax() on the lockup contract.
Lets take a look at how this gets called in the _retrieve() function:
_stream is the proxy contract which will then delegate calls the _target which is the ProxyTarget, lets take a look at withdrawMax() in the SablierV2ProxyTarget :
As you can see this will call the lockup address that was passed in but the problem is that in _retrieve() we have passed in _target as the argument encoded with the selector which is wrong because we need the address of the lockup. This will then call withdrawMax(streamId, to) on the ProxyTarget and because this function does not exist the call will fail.
Impact
Withdrawing from the Sablier stream will always fail and _retrieve() will always fail so the CouncilMember contract will be unusable because _retrieve() is called in almost every function.
1 comment(s) were left on this issue during the judging contest.
takarez commented:
valid because { This is valid and i cosndier it a high due to the fact that main funcitonality will fail; the watson explain how using _target instead of lookUp address causes a problem due to non existent of the called function in the used _target address}
sherlock-admin
changed the title
Alert Quartz Cottonmouth - Wrong Sablier contract is being called in _retrieve()
Arz - Wrong Sablier contract is being called in _retrieve()Jan 29, 2024
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
Arz
medium
Wrong Sablier contract is being called in
_retrieve()
Summary
When
_retrieve()
is called we first call the PRBProxy which delegate calls a Sablier ProxyTarget which then calls the Sablier lockup. the problem here is that the wrong_target
address is being used to callwithdrawMax()
Vulnerability Detail
To withdraw from the Sablier stream we first need to call the PRBProxy which is the recipient of the stream, this proxy will then delegate call SablierV2ProxyTarget which will then call
withdrawMax()
on the lockup contract.Lets take a look at how this gets called in the
_retrieve()
function:_stream
is the proxy contract which will then delegate calls the_target
which is the ProxyTarget, lets take a look atwithdrawMax()
in the SablierV2ProxyTarget :As you can see this will call the
lockup
address that was passed in but the problem is that in_retrieve()
we have passed in_target
as the argument encoded with the selector which is wrong because we need the address of the lockup. This will then callwithdrawMax(streamId, to)
on the ProxyTarget and because this function does not exist the call will fail.Impact
Withdrawing from the Sablier stream will always fail and
_retrieve()
will always fail so the CouncilMember contract will be unusable because_retrieve()
is called in almost every function.Code Snippet
https://github.com/sherlock-audit/2024-01-telcoin/blob/0954297f4fefac82d45a79c73f3a4b8eb25f10e9/telcoin-audit/contracts/sablier/core/CouncilMember.sol#L275C25-L275C25
Tool used
Manual Review
Recommendation
Pass in the address of the Sablier lockup not the TargetProxy.
Duplicate of #139
The text was updated successfully, but these errors were encountered: