Headline
GHSA-5824-cm3x-3c38: Vyper has incorrectly allocated named re-entrancy locks
Impact
In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically:
- A
.vycontract compiled with either of the followingvyperversions:0.2.15,0.2.16,0.3.0 - A primary function that utilizes the
@nonreentrantdecorator with a specifickeyand does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates) - A secondary function that utilizes the same
keyand would be affected by the improper state caused by the primary function
Patches
https://github.com/vyperlang/vyper/pull/2439, https://github.com/vyperlang/vyper/pull/2514
Workarounds
Upgrade to 0.3.1 or higher
References
Technical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2
Package
pip vyper (pip)
Affected versions
>= 0.2.15, < 0.3.1
Patched versions
0.3.1
Description
Impact
In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically:
- A .vy contract compiled with either of the following vyper versions: 0.2.15, 0.2.16, 0.3.0
- A primary function that utilizes the @nonreentrant decorator with a specific key and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates)
- A secondary function that utilizes the same key and would be affected by the improper state caused by the primary function
Patches
vyperlang/vyper#2439, vyperlang/vyper#2514
Workarounds
Upgrade to 0.3.1 or higher
References
Technical post-mortem report: https://hackmd.io/@vyperlang/HJUgNMhs2
References
- GHSA-5824-cm3x-3c38
- https://nvd.nist.gov/vuln/detail/CVE-2023-39363
- vyperlang/vyper#2439
- vyperlang/vyper#2514
- https://hackmd.io/@LlamaRisk/BJzSKHNjn
- https://hackmd.io/@vyperlang/HJUgNMhs2
charles-cooper published to vyperlang/vyper
Aug 5, 2023
Published to the GitHub Advisory Database
Aug 9, 2023
Reviewed
Aug 9, 2023
Last updated
Aug 9, 2023
Severity
Moderate
5.9
/ 10
CVSS base metrics
Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Weaknesses
CWE-863
CVE ID
CVE-2023-39363
GHSA ID
GHSA-5824-cm3x-3c38
Source code
vyperlang/vyper
Checking history
See something to contribute? Suggest improvements for this vulnerability.
Related news
Vyer is a Pythonic Smart Contract Language for the Ethereum Virtual Machine (EVM). In versions 0.2.15, 0.2.16 and 0.3.0, named re-entrancy locks are allocated incorrectly. Each function using a named re-entrancy lock gets a unique lock regardless of the key, allowing cross-function re-entrancy in contracts compiled with the susceptible versions. A specific set of conditions is required to result in misbehavior of affected contracts, specifically: a `.vy` contract compiled with `vyper` versions `0.2.15`, `0.2.16`, or `0.3.0`; a primary function that utilizes the `@nonreentrant` decorator with a specific `key` and does not strictly follow the check-effects-interaction pattern (i.e. contains an external call to an untrusted party before storage updates); and a secondary function that utilizes the same `key` and would be affected by the improper state caused by the primary function. Version 0.3.1 contains a fix for this issue.