Skip to content
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

chore(deps): update dependency @openzeppelin/contracts-upgradeable to v4.4.2 [security] #26

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jan 28, 2022

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@openzeppelin/contracts-upgradeable (source) 4.3.2 -> 4.4.2 age adoption passing confidence

GitHub Vulnerability Alerts

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 ERC1155Supply extension, 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/contracts and @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/contracts and @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.

GHSA-m6w8-fq7v-ph4m

Impact

The GovernorCompatibilityBravo module may lead to the creation of governance proposals that execute function calls with incorrect arguments due to bad ABI encoding. This happens if the proposal is created using explicit function signatures, e.g. a proposal to invoke the function foo(uint256) is created as propose([target], [0], ["foo(uint256)"], ["0x00..01"]). If the function selector is provided as part of the encoded proposal data the issue is not present, e.g. the same proposal is created as propose([target], [0], ["0x2fbebd3800..01"]), where 2fbebd38 is the function selector.

We've assessed the instances of this contract found on chain, and did not find any occurrence of this bug in the past. Proposal creation through Tally or OpenZeppelin Defender is not affected. The core Governor contract on its own is not affected.

Patches

A fix is included in version v4.4.2 of @openzeppelin/contracts and @openzeppelin/contracts-upgradeable.

Workarounds

Do not create proposals using explicit function signatures. Instead, use the propose function without the signatures argument, and create the proposal using the fully ABI-encoded function call including the function selector in the calldatas argument as explained above.

References

OpenZeppelin/openzeppelin-contracts#3099

Credits

This issue was identified and reported by @​GeraldHost.

For more information

If you have any questions, comments, or need assistance regarding this advisory, email us at security@openzeppelin.com.

To submit security reports please use our bug bounty on Immunefi.


Release Notes

OpenZeppelin/openzeppelin-contracts-upgradeable

v4.4.2

Compare Source

Bugfixes
  • GovernorCompatibilityBravo: Fix error in the encoding of calldata for proposals submitted through the compatibility interface with explicit signatures. (#​3100)

v4.4.1

Compare Source

  • Initializable: change the existing initializer modifier and add a new onlyInitializing modifier to prevent reentrancy risk. (#​3006)
Breaking change

It is no longer possible to call an initializer-protected function from within another initializer function 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 new onlyInitializing modifier 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.0

Compare 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: cache address(this) to immutable storage to avoid potential issues if a vanilla contract is used in a delegatecall context. (#​2852)
  • Add internal _setApprovalForAll to ERC721 and ERC1155. (#​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 of toEthSignedMessageHash for arbitrary length message hashing. (#​2865)
  • MerkleProof: add a processProof function 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.3

Compare Source

  • ERC1155Supply: Handle totalSupply changes by hooking into _beforeTokenTransfer to ensure consistency of balances and supply during IERC1155Receiver.onERC1155Received calls.

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.


  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

@vercel
Copy link

vercel bot commented Jan 28, 2022

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

sway-static – ./packages/events/

🔍 Inspect: https://vercel.com/ashutoshvarma/sway-static/BMftqJdr8hoY6sttpzkwH1ucM9z4
✅ Preview: https://sway-static-git-renovate-npm-openzeppelinc-355f61-ashutoshvarma.vercel.app

sway – ./packages/interface

🔍 Inspect: https://vercel.com/ashutoshvarma/sway/6wEygvsJ7Hay3xkkZspXoT5Z3T26
✅ Preview: https://sway-git-renovate-npm-openzeppelincontract-6ad5d2-ashutoshvarma.vercel.app

@renovate renovate bot force-pushed the renovate/npm-@openzeppelin/contracts-upgradeable-vulnerability branch from 7c175d5 to 837301c Compare February 2, 2022 08:05
@ashutoshvarma ashutoshvarma merged commit 4a50437 into main Feb 2, 2022
@ashutoshvarma ashutoshvarma deleted the renovate/npm-@openzeppelin/contracts-upgradeable-vulnerability branch February 2, 2022 08:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants