[GHSA-5824-cm3x-3c38] Vyper has incorrectly allocated named re-entrancy locks

[trocher]

Updates

• Affected products
• CVSS v3
• Severity

Comments
This issue resulted in multiple hack totalling USD 61m loss.
https://cointelegraph.com/news/curve-vyper-exploit-whole-story-so-far

[github]

Hi there @charles-cooper! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[pcaversaccio]

Hey GitHub team, I would like to support the requested change with the following additional resources:

• The Vyper post-mortem with all the details: https://hackmd.io/@vyperlang/HJUgNMhs2
• The Curve post-mortem with all the details (that's the most affected project): https://hackmd.io/@LlamaRisk/BJzSKHNjn
  

Having a reentrancy bug in the compiler itself leading to a loss of >50m is definitely a critical bug.

[shelbyc]

Hi @trocher and @pcaversaccio, dollar amounts lost aren't taken into account when calculating vulnerability severity, but I agree there is room for improvement in the CVSS assessment to make the severity score more closely match the critical severity that @charles-cooper put in the repository advisory for GHSA-5824-cm3x-3c38.

I think this advisory is a good example of where CVSS 4.0, which GitHub recently started supporting in advisories, provides a more accurate assessment of vulnerability severity than CVSS 3.1. I added the exploit maturity metric with a value of A for actively exploited to the end of the base score for CVSS 4.0.

• Here is the current CVSS 3.1 score: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
• Here is the CVSS 4.0 score that I assessed: https://www.first.org/cvss/calculator/v4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:A

Although this gets severity up from medium to high, this still doesn't reach critical because there is only data integrity impact, not confidentiality or availability impact. Vulnerability severity doesn't take into account financial losses, but if it turns out there is impact to data confidentiality or availability that would affect the CVSS.

So the big question: Do the reference links support the idea that only data integrity was affected, or was there a loss of data confidentiality or availability? Availability generally refers to software uptime and usability, rather than e.g. loss of financial resources. Was the money able to be exfiltrated because of threat actors having access to information that should have been confidential, or just because they were able to change the integrity of the data to change who owned the money? I'm interested to hear your thoughts.

[pcaversaccio]

@shelbyc let me try to address your questions:

So the big question: Do the reference links support the idea that only data integrity was affected, or was there a loss of data confidentiality or availability?

A smart contract on Ethereum is a generated bytecode consisting of predefined opcodes. A deployed bytecode can be downloaded by anyone as the Ethereum ledger data is publicly available via so-called network nodes. Thus, I would argue that no data confidentiality itself is affected. However, the affected smart contract bytecodes themselves got bricked by the exploit and a smart contract can be considered as data as well as it holds all of the logic (including the access to the so-called storage trie) and thus the availability got definitely impacted (since you couldn't interact anymore with the affected contracts in a safe way).

Was the money able to be exfiltrated because of threat actors having access to information that should have been confidential, or just because they were able to change the integrity of the data to change who owned the money?

The money got exfiltrated since the compiler code that generates the bytecode had the bug that it forgot to add properly mutex locks even though the high-level language itself specified such a mutex lock. This can be considered a 0-day exploit as until the first exploit, nobody had the information about this critical bug in the compiler code and by exploiting it publicly, other threat actors were able to copycat attack as well.

[shelbyc]

However, the affected smart contract bytecodes themselves got bricked by the exploit and a smart contract can be considered as data as well as it holds all of the logic (including the access to the so-called storage trie) and thus the availability got definitely impacted (since you couldn't interact anymore with the affected contracts in a safe way).

Knowing there's an availability impact definitely impacts the score. Bricking constitutes a high impact so I think it's appropriate to set the availability value to high.

Additionally, I think there's an argument to be made for scope change based on the bug not just allowing account access but allowing exfiltration of money/data from one account to another. Therefore, I want to correct the CVSS scores to:

• CVSS 3.1: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H
• CVSS 4.0: https://www.first.org/cvss/calculator/v4-0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:A

In this case, CVSS 3.1 is still assessed as high, but CVSS 4.0 is assessed as critical and I think CVSS 4.0 is a better fit due to having more specific information about the impact on vulnerable vs. subsequent systems and information about the exploit matury.

@pcaversaccio do these scores look reasonable to you? I'm interested in adding CVSS 4.0 to the advisory and the CVE record.

[pcaversaccio]

@shelbyc much more reasonable now!

I'm interested in adding CVSS 4.0 to the advisory and the CVE record.

Will this happen soon?

[advisory-database]

Hi @trocher! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!

[shelbyc]

Will this happen soon?

The updated CVE record with the updated CVSS is live now! https://www.cve.org/CVERecord?id=CVE-2023-39363