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

build(deps): update dependency @openzeppelin/contracts to 4.4.2 [security] #301

Closed

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jan 21, 2022

WhiteSource Renovate

This PR contains the following updates:

Package Change
@​openzeppelin/contracts 4.3.3 -> 4.4.2

GitHub Vulnerability Alerts

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.


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.

@renovate renovate bot force-pushed the renovate/npm-@openzeppelin/contracts-vulnerability branch from 72300e8 to 4d2855a Compare January 21, 2022 14:25
@renovate
Copy link
Contributor Author

renovate bot commented Jan 21, 2022

⚠ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: package-lock.json
npm WARN using --force I sure hope you know what you are doing.
npm ERR! nested aliases not supported

npm ERR! A complete log of this run can be found in:
npm ERR!     /tmp/renovate-cache/others/npm/_logs/2022-01-21T14_25_30_677Z-debug.log

@Harasz Harasz closed this Jan 24, 2022
@renovate
Copy link
Contributor Author

renovate bot commented Jan 24, 2022

Renovate Ignore Notification

As this PR has been closed unmerged, Renovate will now ignore this update (4.4.2). You will still receive a PR once a newer version is released, so if you wish to permanently ignore this dependency, please add it to the ignoreDeps array of your renovate config.

If this PR was closed by mistake or you changed your mind, you can simply rename this PR and you will soon get a fresh replacement PR opened.

@renovate renovate bot deleted the renovate/npm-@openzeppelin/contracts-vulnerability branch January 24, 2022 11:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants