Update dependency @openzeppelin/contracts to v4.4.1 [SECURITY] - autoclosed #345
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
4.2.0->4.4.1GitHub Vulnerability Alerts
CVE-2021-39167
Impact
A vulnerability in
TimelockControllerallowed an actor with the executor role to take immediate control of the timelock, by resetting the delay to 0 and escalating privileges, thus gaining unrestricted access to assets held in the contract. Instances with the executor role set to "open" allow anyone to use the executor role, thus leaving the timelock at risk of being taken over by an attacker.Patches
A fix is included in the following releases of
@openzeppelin/contractsand@openzeppelin/contracts-upgradeable:Deployed instances of
TimelockControllershould be replaced with a fixed version by migrating all assets, ownership, and roles.Workarounds
Revoke the executor role from accounts not strictly under the team's control. We recommend revoking all executors that are not also proposers. When applying this mitigation, ensure there is at least one proposer and executor remaining.
References
Post-mortem.
Credits
The issue was identified by an anonymous white hat hacker through Immunefi.
For more information
If you have any questions or comments about this advisory, or need assistance executing the mitigation, email us at security@openzeppelin.com.
CVE-2021-41264
Impact
Upgradeable contracts using
UUPSUpgradeablemay be vulnerable to an attack affecting uninitialized implementation contracts. We will update this advisory with more information soon.Patches
A fix is included in version 4.3.2 of
@openzeppelin/contractsand@openzeppelin/contracts-upgradeable.Workarounds
Initialize implementation contracts using
UUPSUpgradeableby invoking the initializer function (usually calledinitialize). An example is provided in the forum.References
Post-mortem.
For more information
If you have any questions or comments about this advisory, or need assistance executing the mitigation, email us at security@openzeppelin.com.
GHSA-wmpv-c2jp-j2xg
When ERC1155 tokens are minted, a callback is invoked on the receiver of those tokens, as required by the spec. When including the
ERC1155Supplyextension, total supply is not updated until after the callback, thus during the callback the reported total supply is lower than the real number of tokens in circulation.Impact
If a system relies on accurately reported supply, an attacker may be able to mint tokens and invoke that system after receiving the token balance but before the supply is updated.
Patches
A fix is included in version 4.3.3 of
@openzeppelin/contractsand@openzeppelin/contracts-upgradeable.Workarounds
If accurate supply is relevant, do not mint tokens to untrusted receivers.
Credits
The issue was identified and reported by @ChainSecurityAudits.
For more information
Read TotalSupply Inconsistency in ERC1155 NFT Tokens by @ChainSecurityAudits for a more detailed breakdown.
If you have any questions or comments about this advisory, email us at security@openzeppelin.com.
GHSA-9c22-pwxw-p6hx
Impact
Initializer functions that are invoked separate from contract creation (the most prominent example being minimal proxies) may be reentered if they make an untrusted non-view external call.
Once an initializer has finished running it can never be re-executed. However, an exception put in place to support multiple inheritance made reentrancy possible in the scenario described above, breaking the expectation that there is a single execution.
Note that upgradeable proxies are commonly initialized together with contract creation, where reentrancy is not feasible, so the impact of this issue is believed to be minor.
Patches
A fix is included in the version v4.4.1 of
@openzeppelin/contractsand@openzeppelin/contracts-upgradeable.Workarounds
Avoid untrusted external calls during initialization.
References
OpenZeppelin/openzeppelin-contracts#3006
Credits
This issue was identified and reported by @chaitinblockchain through our bug bounty on Immunefi.
For more information
If you have any questions or comments about this advisory, or need assistance executing the mitigation, email us at security@openzeppelin.com.
CVE-2021-46320
In OpenZeppelin <=v4.4.0, initializer functions that are invoked separate from contract creation (the most prominent example being minimal proxies) may be reentered if they make an untrusted non-view external call. Once an initializer has finished running it can never be re-executed. However, an exception put in place to support multiple inheritance made reentrancy possible, breaking the expectation that there is a single execution.
Release Notes
OpenZeppelin/openzeppelin-contracts
v4.4.1Compare Source
Initializable: change the existinginitializermodifier and add a newonlyInitializingmodifier to prevent reentrancy risk. (#3006)Breaking change
It is no longer possible to call an
initializer-protected function from within anotherinitializerfunction outside the context of a constructor. Projects using OpenZeppelin upgradeable proxies should continue to work as is, since in the common case the initializer is invoked in the constructor directly. If this is not the case for you, the suggested change is to use the newonlyInitializingmodifier in the following way:contract A { - function initialize() public initializer { ... } + function initialize() internal onlyInitializing { ... } } contract B is A { function initialize() public initializer { A.initialize(); } }v4.4.0Compare Source
Ownable: add an internal_transferOwnership(address). (#2568)AccessControl: add internal_grantRole(bytes32,address)and_revokeRole(bytes32,address). (#2568)AccessControl: mark_setupRole(bytes32,address)as deprecated in favor of_grantRole(bytes32,address). (#2568)AccessControlEnumerable: hook into_grantRole(bytes32,address)and_revokeRole(bytes32,address). (#2946)EIP712: cacheaddress(this)to immutable storage to avoid potential issues if a vanilla contract is used in a delegatecall context. (#2852)_setApprovalForAlltoERC721andERC1155. (#2834)Governor: shift vote start and end by one block to better match Compound's GovernorBravo and prevent voting at the Governor level if the voting snapshot is not ready. (#2892)GovernorCompatibilityBravo: consider quorum an inclusive rather than exclusive minimum to match Compound's GovernorBravo. (#2974)GovernorSettings: a new governor module that manages voting settings updatable through governance actions. (#2904)PaymentSplitter: now supports ERC20 assets in addition to Ether. (#2858)ECDSA: add a variant oftoEthSignedMessageHashfor arbitrary length message hashing. (#2865)MerkleProof: add aprocessProoffunction that returns the rebuilt root hash given a leaf and a proof. (#2841)VestingWallet: new contract that handles the vesting of Ether and ERC20 tokens following a customizable vesting schedule. (#2748)Governor: enable receiving Ether when a Timelock contract is not used. (#2748)GovernorTimelockCompound: fix ability to use Ether stored in the Timelock contract. (#2748)v4.3.3Compare Source
ERC1155Supply: HandletotalSupplychanges by hooking into_beforeTokenTransferto ensure consistency of balances and supply duringIERC1155Receiver.onERC1155Receivedcalls.v4.3.2Compare Source
UUPSUpgradeable: Add modifiers to preventupgradeToandupgradeToAndCallbeing executed on any contract that is not the active ERC1967 proxy. This prevents these functions being called on implementation contracts or minimal ERC1167 clones, in particular.v4.3.1Compare Source
TimelockController: Add additional isOperationReady check.v4.3.0Compare Source
ERC2771Context: use private variable from storage to store the forwarder address. Fixes issues where_msgSender()was not callable from constructors. (#2754)EnumerableSet: addvalues()functions that returns an array containing all values in a single call. (#2768)Governor: added a modular system ofGovernorcontracts based onGovernorAlphaandGovernorBravo. (#2672)interfacesfolder containing solidity interfaces to final ERCs. (#2517)ECDSA: addtryRecoverfunctions that will not throw if the signature is invalid, and will return an error flag instead. (#2661)SignatureChecker: Reduce gas usage of theisValidSignatureNowfunction for the "signature by EOA" case. (#2661)Configuration
📅 Schedule: "" (UTC).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by WhiteSource Renovate. View repository job log here.