-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
p-tsanev - TelcoinDistributor.sol - Pausing the contract would disable challenging transactions #24
Comments
1 comment(s) were left on this issue during the judging contest. takarez commented:
|
Escalate This is invalid issue. The contract can only be paused by owner of contract and the owner is trusted.
Even if the external integration is considered, Pausing of contract is acceptable to protocol team,
Let me highlight Sherlock rules for trusted admin resulting in invalid issues,
Since, admin is trusted and it is expected from admin that before pausing the contract, all council members would be notified via some medium and it can be further assumed that all pending proposal would be executed before pausing the contract and there is no such issue can happen except malicious owner purposefully allows it council members. I think, the issue could be valid if the admin was restricted with specific mention of pausing the contract in contest readme.md. Feel free to correct, if i am missing something. |
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
I would like to say that it can be mitigated by admin by waiting malicious transaction to expire in paused state. I think it should remain medium if 1. waiting for expiration is not acceptable (maybe too long) or 2. expiration of other legitimate transactions is not acceptable @0xMR0 council member can be malicious
|
Escalate |
You've created a valid escalation! To remove the escalation from consideration: Delete your comment. You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final. |
This should remain medium severity based off @0xLogos comments. He brought up really good points, but you can see that point 1 directly contradicts with point 2. Waiting for too long will cause legitimate proposals to be unfairly excluded too, and then the same situation can happen again when a pause is again executed (be it accidental or on purpose proposal proposed before pause is invoked), so to me this breaks core contract functionality, because you cannot make sure that all of the legitimate proposals are executed while waiting for expiration. Although pausing is a sensitive and rare situation, because this directly undermines the execution of legitimate proposals and possibly even allow malicious proposals to go through, I believe this warrants medium severity. |
I agree with @nevillehuang |
Respectfully disagree with above comments.
While i agree, the issue could be low severity but its invalid at sherlock. I would agree with @Czar102 final judgment on this issue without further arguments. |
Respectfully disagree with the above comment:
|
Agree with @PlamenTSV the points made by @0xMR0 are simply assumptions and too dangerous, especially point 2, semi trusted does not mean they can decide whatever they want. This is why a challenge mechanism exists in the first place and should be applied consistently, be it in a paused state or not. |
I don't believe this issue should be rewarded. I believe it's a design choice to pause the This issue illustrates a scenario where pausing the I believe this language applies
|
Result: |
Escalations have been resolved successfully! Escalation status:
|
The protocol team fixed this issue in PR/commit https://github.com/telcoin/telcoin-audit/pull/29. |
The Lead Senior Watson signed-off on the fix. |
p-tsanev
medium
TelcoinDistributor.sol - Pausing the contract would disable challenging transactions
Summary
The TelcoinDistributor contract allows for the proposal, execution and challenging(cancellation) of transactions. It also introduces pausing functionality, probably to deal with external integration pausing and as a security measure. This functionality can give unfair advantage to proposers.
Vulnerability Detail
The functions for executing and creating proposals are correctly safe-guarded with the
whenNotPaused
modifier, stopping the creation and execution of proposals. But an unfair advantage is created because thechallengeTransaction
function has thewhenNotPaused
modifier as well.Depending the the duration of the pause it is highly possible for proposals created before the pause, either intentionally via front-running or accidentally, to pass their challenge period, giving council members no way to challenge. Thus creating an unfair advantage during the pause and potentially allowing malicious/unfavorable transactions to reach execution.
Impact
Unfair advantage during pause, potential stealing of funds from the
owner()
due to inability to challenge proposalCode Snippet
https://github.com/sherlock-audit/2024-01-telcoin/blob/main/telcoin-audit/contracts/protocol/core/TelcoinDistributor.sol#L115-L136
Tool used
Manual Review
Recommendation
Remove the
whenNotPaused
modifier from thechallengeTransaction
function.The text was updated successfully, but these errors were encountered: