GHSA-w9g2-3w7p-72g9 CVE-2023-30629 PYSEC-2023-131
Incorrect success value returned in vyper
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.88%
- Chance of exploitation in the next 30 days. Higher than 59.20% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-670 Always-Incorrect Control Flow Implementation
- Fix
0.3.8- Upgrade vyper to this version or later
Description
Background
During the audit of Lido's Gate Seals code statemind team identified a weird behavior of the code that uses raw_call: https://github.com/lidofinance/gate-seals/blob/051593e74df01a4131c485b4fda52e691cd4b7d8/contracts/GateSeal.vy#L164 .
Construction like this:
success = raw_call(
sealable,
_abi_encode(SEAL_DURATION_SECONDS, method_id=method_id("pauseFor(uint256)")),
revert_on_failure=False
)
was not fully documented: https://docs.vyperlang.org/en/v0.3.7/built-in-functions.html#raw_call .
The documentation says that: if max_outsize=0 it should return nothing and then it says that if revert_on_failure=False it should return a success flag in the tuple of response, but what if max_outsize=0 and revert_on_failure=False.
<img width="715" alt="image" src="https://user-images.githubusercontent.com/22330612/232125364-d2b3bbac-0b4f-40cb-80ff-f55d8eafef44.png">
So the team started researching what exactly happened in that case, after some research we found that the Vyper compiler generates the wrong bytecode in that case, it generates the sequence:
CALL // call
MLOAD // MLOAD is wrong since the CALL result is already stored in the stack
Impact
Example of buggy code:
@external
def returnSome(calling: address, a: uint256) -> bool:
success: bool = false
success = raw_call(
calling,
_abi_encode(a, method_id=method_id("a(uint256)")),
revert_on_failure=False
)
any contract that uses the raw_call with revert_on_failure=False and max_outsize=0 receives the wrong response from raw_call. Depending on the memory garbage, the result can be either True or False.
Patches
Fix by @charles-cooper https://github.com/vyperlang/vyper/commit/851f7a1b3aa2a36fd041e3d0ed38f9355a58c8ae
Workarounds
The simple workaround is always to put max_outsize>0.
Workaround example https://github.com/lidofinance/gate-seals/pull/5/files
References
Lido's fix: https://github.com/lidofinance/gate-seals/pull/5/files
Affected versions
PyPI
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
vyper PyPI → 0.3.8
- pip
pip install --upgrade "vyper>=0.3.8"- poetry
poetry add "vyper>=0.3.8"- uv
uv add "vyper>=0.3.8"
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Weakness
CWE-670: Always-Incorrect Control Flow Implementation
The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated.
References
Advisories
Packages
Other links
- github.com/vyperlang/vyper/security/advisories/GHSA-w9g2-3w7p-72g9
- github.com/lidofinance/gate-seals/pull/5/files
- github.com/vyperlang/vyper/commit/851f7a1b3aa2a36fd041e3d0ed38f9355a58c8ae
- docs.vyperlang.org/en/v0.3.7/built-in-functions.html
- github.com/lidofinance/gate-seals/blob/051593e74df01a4131c485b4fda52e691cd4b7d8…
- github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2023-131.yaml
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-2r3x-4mrv-mcxf Vyper: Memory corruption using function calls within tuples / nested calls | Medium | Also affects vyper |
| GHSA-4v7v-gqf9-ww2g Vyper: Call stack corruption when passing complex type containing non-base type members as argument | Medium | Also affects vyper |
| GHSA-vg88-3v92-rjx2 Vyper: Return inside for loop more than 1 level deep | Low | Also affects vyper |
| GHSA-3vcg-j39x-cwfm Vyper's `slice()` may elide side-effects when output length is 0 | Low | Also affects vyper |
| GHSA-qhr6-mgqr-mchm Vyper's `concat()` builtin may elide side-effects for zero-length arguments | Low | Also affects vyper |
| GHSA-h33q-mhmp-8p67 Vyper has a double eval in For List Iter | High | Also affects vyper |
| GHSA-4w26-8p97-f4jp AugAssign evaluation order causing OOB write within the object in Vyper | Critical | Also affects vyper |
| GHSA-2p94-8669-xg86 Vyper's sqrt doesn't define rounding behavior | High | Also affects vyper |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor