-
Notifications
You must be signed in to change notification settings - Fork 369
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
Prevent CELO Transfer to Unreleased Treasury #11222
Prevent CELO Transfer to Unreleased Treasury #11222
Conversation
no working test. Co-authored-by: Martín Volpe <[email protected]>
…o into feat/epoch-manager
I'd add a fallback function and make it revert to make sure nobody overlooks this in the future |
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
10538986 | Triggered | Generic High Entropy Secret | efebfb7 | packages/protocol/scripts/foundry/constants.sh | View secret |
10538986 | Triggered | Generic High Entropy Secret | 04af0f7 | packages/protocol/scripts/foundry/constants.sh | View secret |
10538986 | Triggered | Generic High Entropy Secret | 29aadbb | packages/protocol/scripts/foundry/constants.sh | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
…ransfer-to-unreleased-treasury
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, one comment about a missing test.
One concern: do we still have SELFDESTRUCT that will send CELO unconditionally? If so, this change is unfortunately somewhat moot.
This is a valid point. Will have to think about mitigation for this case. |
If there is still SELFDESTRUCT, I think @pahor167's comment here becomes much more relevant - if this change doesn't fully provide the intended mitigation, might not be worth it to increase CELO ERC20 transfer costs. Would a potential alternative solution be to keep account of the unreleased CELO within this contract, and simply ignore any balance transferred to it? I.e. for any calculations, rather than using |
Yes, thats what I was thinking would be an alternate solution to this. We could then remove the CELOToken check to keep the ERC20 transfer gas low |
Prevent CELO Transfer to Unreleased Treasury
🚨 Report Summary
For more details view the full report in OpenZeppelin Code Inspector |
…ransfer-to-unreleased-treasury
remainingBalanceToRelease = address(this).balance; | ||
hasAlreadyReleased = true; | ||
} | ||
|
||
require(remainingBalanceToRelease >= amount, "Insufficient balance."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd use ERC20 balance so that it can be ported to another token if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand what you mean by porting to another token. As in distributing a different ERC20 token instead of CELO?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we ever want to use this contract for another ERC20, it won't work at we use ERC20 interfaces instead of native ones.
|
||
import "../../contracts/common/Initializable.sol"; | ||
import "./interfaces/ICeloUnreleasedTreasuryInitializer.sol"; | ||
|
||
/** | ||
* @title Contract for unreleased Celo tokens. | ||
* @notice This contract is not allowed to receive transfers of CELO, | ||
* to avoid miscalculating the epoch rewards and to prevent any malicious actor | ||
* from routing stolen fund through the epoch reward distribution. | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make the fallback payable function explicitly revert?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add a fallback function to make it explicitly revert, but that would acheive the same result as it is currently.
vm.prank(sender); | ||
uint256 balanceBefore = celoToken.balanceOf(celoUnreleasedTreasuryAddress); | ||
|
||
celoToken.transfer(celoUnreleasedTreasuryAddress, ONE_CELOTOKEN); | ||
uint256 balanceAfter = celoToken.balanceOf(celoUnreleasedTreasuryAddress); | ||
assertGt(balanceAfter, balanceBefore); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't this fail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if ERC20 token transfer succeed, for consistency shouldn't we make native transfer for as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This follows the same pattern as all other core contracts. No fallback implemented but still receive ERC20 transfers. Since it now keeps an internal accounting of the remaining distribution, any transfers are ignored.
…ransfer-to-unreleased-treasury
Description
I propose this change to prevent sending funds back to the the
CeloUnreleasedTreasury
because theepochRewards
contract uses the funds left in that contract to calculate the epoch rewards to be distributed.This could potentially be used by malicious actors wanting to hide their identity, by registering as validator(elected) and/or voters, then sending stolen fund back to the
CeloUnreleasedTreasury
and receiving the stolen funds as rewards.Although this scenario would distribute the funds to all validators and voters, depending on the amount it could be appealing.
In addition to that, any stolen funds received by legitimate validators could become a legal burden.
Tested
unit tests updated
Closes https://github.com/celo-org/celo-blockchain-planning/issues/643