CVE-2023-39363

Błędna alokacja blokad re-entrancy w Vyper — cross-function re-entrancy

CVSS 9.1v4.0pub. 2023-08-07upd. 2024-11-21

W kompilatorze Vyper w wersjach 0.2.15, 0.2.16 i 0.3.0 nazwane blokady re-entrancy (named re-entrancy locks) są przydzielane nieprawidłowo, co umożliwia atak cross-function re-entrancy na smart kontrakty skompilowane tymi wersjami. Jest to krytyczna podatność dla aplikacji DeFi i innych kontraktów Ethereum obsługujących środki użytkowników.

▸ Pokaż oryginał (EN)

Vyper 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.

🤖 Analiza AI

Jak działa

Mechanizm dekoratora `@nonreentrant` z określonym kluczem (`key`) powinien zapewniać, że wszystkie funkcje używające tego samego klucza dzielą jedną blokadę. W podatnych wersjach każda funkcja korzystająca z nazwanej blokady re-entrancy otrzymuje własną, niezależną blokadę — niezależnie od użytego klucza. Pozwala to atakującemu na wejście do drugiej funkcji kontraktu podczas wykonywania pierwszej, zanim zostaną utrwalone zmiany stanu (storage updates). Warunkiem koniecznym jest naruszenie wzorca check-effects-interaction w funkcji podstawowej — tzn. obecność zewnętrznego wywołania do niezaufanej strony przed aktualizacją storage, oraz istnienie drugiej funkcji używającej tego samego klucza, podatnej na nieprawidłowy stan wywołany przez funkcję podstawową.

Skutki

Atakujący może wielokrotnie wywoływać funkcje kontraktu w sposób nieprzewidziany przez dewelopera, manipulując stanem kontraktu przed jego aktualizacją. W praktyce może to prowadzić do nieautoryzowanego wyprowadzenia środków finansowych lub trwałego uszkodzenia stanu kontraktu (naruszenie integralności danych i dostępności).

Mitygacja

Należy zaktualizować kompilator Vyper do wersji 0.3.1 lub nowszej, która zawiera poprawkę dla tego błędu. Wszystkie kontrakty skompilowane podatnymi wersjami (0.2.15, 0.2.16, 0.3.0) wymagają ponownej kompilacji i wdrożenia po aktualizacji kompilatora. Do czasu migracji należy rozważyć wstrzymanie działania narażonych kontraktów, jeśli przetwarzają one środki użytkowników.

Kogo dotyczy

Smart kontrakty napisane w języku Vyper i skompilowane przy użyciu wersji 0.2.15, 0.2.16 lub 0.3.0, które korzystają z dekoratora `@nonreentrant` z nazwanym kluczem i nie przestrzegają ściśle wzorca check-effects-interaction.

Uwagi

Podatność dotyczy etapu kompilacji — sam kod źródłowy kontraktu może być poprawny, jednak błędnie skompilowany binarny bytecode jest podatny. Kontrakty już wdrożone na sieci Ethereum wymagają przeprowadzenia migracji, ponieważ nie można ich zaktualizować bez ponownego wdrożenia.

CVSS Vector

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/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X