Update dependency @openzeppelin/contracts to v4.9.6 [SECURITY] #14
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.8.0->4.9.6GitHub Vulnerability Alerts
CVE-2023-34234
Impact
By frontrunning the creation of a proposal, an attacker can become the proposer and gain the ability to cancel it. The attacker can do this repeatedly to try to prevent a proposal from being proposed at all.
This impacts the
Governorcontract in v4.9.0 only, and theGovernorCompatibilityBravocontract since v4.3.0.Patches
The problem has been patched in 4.9.1 by introducing opt-in frontrunning protection.
Workarounds
Submit the proposal creation transaction to an endpoint with frontrunning protection.
Credit
Reported by Lior Abadi and Joaquin Pereyra from Coinspect.
References
https://www.coinspect.com/openzeppelin-governor-dos/
CVE-2023-34459
Impact
When the
verifyMultiProof,verifyMultiProofCalldata,processMultiProof, orprocessMultiProofCalldatafunctions are in use, it is possible to construct merkle trees that allow forging a valid multiproof for an arbitrary set of leaves.A contract may be vulnerable if it uses multiproofs for verification and the merkle tree that is processed includes a node with value 0 at depth 1 (just under the root). This could happen inadvertently for balanced trees with 3 leaves or less, if the leaves are not hashed. This could happen deliberately if a malicious tree builder includes such a node in the tree.
A contract is not vulnerable if it uses single-leaf proving (
verify,verifyCalldata,processProof, orprocessProofCalldata), or if it uses multiproofs with a known tree that has hashed leaves. Standard merkle trees produced or validated with the @openzeppelin/merkle-tree library are safe.Patches
The problem has been patched in 4.9.2.
Workarounds
If you are using multiproofs: When constructing merkle trees hash the leaves and do not insert empty nodes in your trees. Using the @openzeppelin/merkle-tree package eliminates this issue. Do not accept user-provided merkle roots without reconstructing at least the first level of the tree. Verify the merkle tree structure by reconstructing it from the leaves.
CVE-2023-40014
Impact
OpenZeppelin Contracts is a library for secure smart contract development. Starting in version 4.0.0 and prior to version 4.9.3, contracts using
ERC2771Contextalong with a custom trusted forwarder may see_msgSenderreturnaddress(0)in calls that originate from the forwarder with calldata shorter than 20 bytes. This combination of circumstances does not appear to be common, in particular it is not the case forMinimalForwarderfrom OpenZeppelin Contracts, or any deployed forwarder the team is aware of, given that the signer address is appended to all calls that originate from these forwarders.Patches
The problem has been patched in v4.9.3.
CVE-2024-27094
Impact
The
Base64.encodefunction encodes abytesinput by iterating over it in chunks of 3 bytes. When this input is not a multiple of 3, the last iteration may read parts of the memory that are beyond the input buffer.Although the
encodefunction pads the output for these cases, up to 4 bits of data are kept between the encoding and padding, corrupting the output if these bits were dirty (i.e. memory after the input is not 0). These conditions are more frequent in the following scenarios:bytes memorystruct is allocated just after the input and the first bytes of it are non-zero.Developers should evaluate whether the extra bits can be maliciously manipulated by an attacker.
Patches
Upgrade to 5.0.2 or 4.9.6.
References
This issue was reported by the Independent Security Researcher Riley Holterhus through Immunefi (@rileyholterhus on X)
Release Notes
OpenZeppelin/openzeppelin-contracts (@openzeppelin/contracts)
v4.9.6Compare Source
Base64: Fix issue where dirty memory located just after the input buffer is affecting the result. (#4929)v4.9.5Compare Source
Multicall: Make aware of non-canonical context (i.e.msg.senderis not_msgSender()), allowing compatibility withERC2771Context. Patch duplicatedAddress.functionDelegateCallin v4.9.4 (removed).v4.9.4Compare Source
ERC2771ContextandContext: Introduce a_contextPrefixLength()getter, used to trim extra information appended tomsg.data.Multicall: Make aware of non-canonical context (i.e.msg.senderis not_msgSender()), allowing compatibility withERC2771Context.v4.9.3Compare Source
ERC2771Context: Return the forwarder address whenever themsg.dataof a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e.msg.data.lengthis less than 20 bytes), as specified by ERC-2771. (#4481)ERC2771Context: Prevent revert in_msgData()when a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e.msg.data.lengthis less than 20 bytes). Return the full calldata in that case. (#4484)v4.9.2Compare Source
MerkleProof: Fix a bug inprocessMultiProofandprocessMultiProofCalldatathat allows proving arbitrary leaves if the tree contains a node with value 0 at depth 1.v4.9.1Compare Source
Governor: Add a mechanism to restrict the address of the proposer using a suffix in the description.v4.9.0Compare Source
ReentrancyGuard: Add a_reentrancyGuardEnteredfunction to expose the guard status. (#3714)ERC721Wrapper: add a new extension of theERC721token which wraps an underlying token. Deposit and withdraw guarantee that the ownership of each token is backed by a corresponding underlying token with the same identifier. (#3863)EnumerableMap: add akeys()function that returns an array containing all the keys. (#3920)Governor: add a publiccancel(uint256)function. (#3983)Governor: Enable timestamp operation for blockchains without a stable block time. This is achieved by connecting a Governor's internal clock to match a voting token's EIP-6372 interface. (#3934)Strings: addequalmethod. (#3774)IERC5313: Add an interface for EIP-5313 that is now final. (#4013)IERC4906: Add an interface for ERC-4906 that is now Final. (#4012)StorageSlot: Add support forstringandbytes. (#4008)Votes,ERC20Votes,ERC721Votes: support timestamp checkpointing using EIP-6372. (#3934)ERC4626: Add mitigation to the inflation attack through virtual shares and assets. (#3979)Strings: addtoStringmethod for signed integers. (#3773)ERC20Wrapper: Make theunderlyingvariable private and add a public accessor. (#4029)EIP712: add EIP-5267 support for better domain discovery. (#3969)AccessControlDefaultAdminRules: Add an extension ofAccessControlwith additional security rules for theDEFAULT_ADMIN_ROLE. (#4009)SignatureChecker: AddisValidERC1271SignatureNowfor checking a signature directly against a smart contract using ERC-1271. (#3932)SafeERC20: Add aforceApprovefunction to improve compatibility with tokens behaving like USDT. (#4067)ERC1967Upgrade: removed contract-wideoz-upgrades-unsafe-allow delegatecallannotation, replaced by granular annotation inUUPSUpgradeable. (#3971)ERC20Wrapper: self wrapping and deposit by the wrapper itself are now explicitly forbidden. (#4100)ECDSA: optimize bytes32 computation by using assembly instead ofabi.encodePacked. (#3853)ERC721URIStorage: Emit ERC-4906MetadataUpdatein_setTokenURI. (#4012)ShortStrings: Added a library for handling short strings in a gas efficient way, with fallback to storage for longer strings. (#4023)SignatureChecker: Allow return data length greater than 32 from EIP-1271 signers. (#4038)UUPSUpgradeable: added granularoz-upgrades-unsafe-allow-reachableannotation to improve upgrade safety checks on latest version of the Upgrades Plugins (starting with@openzeppelin/[email protected]). (#3971)Initializable: optimize_disableInitializersby using!=instead of<. (#3787)Ownable2Step: makeacceptOwnershippublic virtual to enable usecases that require overriding it. (#3960)UUPSUpgradeable.sol: Change visibility to the functionsupgradeToandupgradeToAndCallfromexternaltopublic. (#3959)TimelockController: Add theCallSaltevent to emit on operation schedule. (#4001)Math: optimizelog256rounding check. (#3745)ERC20Votes: optimize by using unchecked arithmetic. (#3748)Multicall: annotatemulticallfunction as upgrade safe to not raise a flag for its delegatecall. (#3961)ERC20Pausable,ERC721Pausable,ERC1155Pausable: Add note regarding missing public pausing functionality (#4007)ECDSA: Add a functiontoDataWithIntendedValidatorHashthat encodes data with version 0x00 following EIP-191. (#4063)MerkleProof: optimize by using unchecked arithmetic. (#3745)Breaking changes
EIP712: Addition of ERC5267 support requires support for user defined value types, which was released in Solidity version 0.8.8. This requires a pragma change from^0.8.0to^0.8.8.EIP712: Optimization of the cache for the upgradeable version affects the waynameandversionare set. This is no longer done through an initializer, and is instead part of the implementation's constructor. As a consequence, all proxies using the same implementation will necessarily share the samenameandversion. Additionally, an implementation upgrade risks changing the EIP712 domain unless the samenameandversionare used when deploying the new implementation contract.Deprecations
ERC20Permit: Added the fileIERC20Permit.solandERC20Permit.soland deprecateddraft-IERC20Permit.solanddraft-ERC20Permit.solsince EIP-2612 is no longer a Draft. Developers are encouraged to update their imports. (#3793)Timers: TheTimerslibrary is now deprecated and will be removed in the next major release. (#4062)ERC777: TheERC777token standard is no longer supported by OpenZeppelin. Our implementation is now deprecated and will be removed in the next major release. The corresponding standard interfaces remain available. (#4066)ERC1820Implementer: TheERC1820pseudo-introspection mechanism is no longer supported by OpenZeppelin. Our implementation is now deprecated and will be removed in the next major release. The corresponding standard interfaces remain available. (#4066)v4.8.3Compare Source
GovernorCompatibilityBravo: Fix encoding of proposal data when signatures are missing.TransparentUpgradeableProxy: Fix transparency in case of selector clash with non-decodable calldata or payable mutability. (#4154)v4.8.2Compare Source
ERC721Consecutive: Fixed a bug when_mintConsecutiveis used for batches of size 1 that could lead to balance overflow. Refer to the breaking changes section in the changelog for a note on the behavior ofERC721._beforeTokenTransfer.Breaking changes
ERC721: The internal function_beforeTokenTransferno longer updates balances, which it previously did whenbatchSizewas greater than 1. This change has no consequence unless a custom ERC721 extension is explicitly invoking_beforeTokenTransfer. Balance updates in extensions must now be done explicitly using__unsafe_increaseBalance, with a name that indicates that there is an invariant that has to be manually verified.v4.8.1Compare Source
ERC4626: Use staticcall instead of call when fetching underlying ERC-20 decimals. (#3943)Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 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 was generated by Mend Renovate. View the repository job log.