Podatności Wasmtime

Wasmtime przed wersjami 36.0.19, 48.0.7 i 49.0.4 posiada błąd w kompilatorze Cranelift na architekturze aarch64. Instrukcja br_table z ponad 256 000 celów może zostać błędnie skompilowana, umożliwiając skok do dowolnego kodu i ucieczkę z sandboxa.

Wasmtime przed wersjami 36.0.19 i 43.0.0 ma błąd w kompilatorze Cranelift polegający na cichym przepełnieniu indeksów SSA przy kompilacji dużych funkcji Wasm. Może to prowadzić do błędnej kompilacji, pomieszania typów i ucieczki z sandboxa.

Wasmtime w wersjach 39.0.0 przed 48.0.4 oraz 49.0.0 przed 49.0.2 zawiera przepełnienie bufora stosu, które pozwala złośliwym gościom zapisać około 16 KB na natywnym stosie poprzez niezwalidowane typy wyników asynchronicznych wywołań zwrotnych. Atakujący może dostarczyć komponenty z błędnie otypowanymi funkcjami callback component-model-async, aby nadpisać adresy powrotu, powodując awarię hosta lub ucieczkę z piaskownicy.

Podatność w środowisku uruchomieniowym Wasmtime dotyczy kompilatora Winch (backend niestandardowy, nieużywany domyślnie). Błąd pozwala odpowiednio spreparowanemu kodowi Wasm na dostęp do pamięci hosta poza piaskownicą pamięci liniowej. Wymaga to włączenia kompilatora Winch opcją -Ccompiler=winch; domyślny backend Cranelift nie jest podatny.

Wasmtime w wersjach 46.0.0 do 48.0.6 oraz 49.0.0 do 49.0.3 zawiera podatność typu denial of service, która pozwala kodowi gościa wywołać panikę hosta poprzez operacje strumieniowe o zerowej długości poza zakresem. Złośliwy gość może wykonać odczyt lub zapis strumienia modelu komponentów o zerowej długości z niezwalidowanymi adresami, powodując panikę i awarię osadzających WASIp3.

Wasmtime w wersjach 46.0.0 do 48.0.6 oraz 49.0.0 do 49.0.3 zawiera podatność typu denial of service, w której porzucenie obiektu Future zwróconego przez TypedFunc::call_async może wywołać panikę hosta. Gdy zadanie gościa nie zostało rozpoczęte, kod czyszczący szuka elementów pracy tylko w jednym miejscu i odpakowuje wynikowy błąd, powodując awarię osadzających, którzy anulują oczekujące wywołania.

Wasmtime w wersjach 46.0.0 do 48.0.6 oraz 49.0.0 do 49.0.3 zawiera podatność typu denial of service, która pozwala złośliwym modułom Wasm wywołać panikę hosta, ponieważ flaga may_leave nie jest czyszczona podczas realloc. Atakujący może wywołać kod hosta z realloc podczas obniżania wyników strumieni lub future, np. anulując aktywny odczyt lub ponownie oczekując na waitable-set, powodując awarię hosta.

Wasmtime w wersjach 46.0.0 do 48.0.6 oraz 49.0.0 do 49.0.3 zawiera podatność typu denial of service, która pozwala złośliwym komponentom wywołać panikę hosta poprzez thread.yield w funkcjach startowych. Atakujący może dostarczyć komponent, którego funkcja startowa wywołuje asynchronicznie obniżony import, a następnie thread.yield, powodując porzucenie nieusuniętego fiber i awarię osadzających.

Wasmtime w wersjach 46.0.0–48.0.5 i 49.0.0–49.0.2 zawiera pozostałą asercję w component::Func::call, która odrzuca eksporty gościa korzystające z opcji async ABI. Atakujący dostarczający komponent z eksportem async-lifted może spowodować awarię procesu hosta, gdy embedder wywoła ten eksport przez Func::call.

Wasmtime w wersjach 46.0.0–48.0.5 i 49.0.0–49.0.2 zawiera podatność typu denial of service, w której oczekujące wywołania mogą wywołać błąd asercji po zatruciu Store przez trap. Atakujący dostarczający błędnie działający kod gościa może wywołać trap i pozwolić wcześniejszym wywołaniom kontynuować, powodując awarię embedderów używających niespójnego Store.

Wasmtime w wersjach 42.0.0–48.0.5 i 49.0.0–49.0.2 zawiera podatność przepełnienia stosu, która pozwala gościom na crash hosta poprzez rekurencyjne usuwanie typów. Goście mogą zdefiniować długi łańcuch typów rekurencyjnych, tak że usunięcie typu najwyższego poziomu wywołuje nieograniczone rekurencyjne usuwanie, wyczerpując stos hosta.

Wasmtime w wersjach 42.0.0–48.0.5 i 49.0.0–49.0.2 zawiera niewystarczające sprawdzenia w Store przy mieszaniu wywołań WebAssembly w stylu asynchronicznym i synchronicznym. Embeddery ponownie wchodzące do WebAssembly przez synchroniczne API z funkcji hosta wywoływanych asynchronicznie mogą wywołać paniki runtime lub niebezpieczne przenoszenie zmiennych hosta !Send między wątkami.

Wasmtime w wersjach 46.0.0–48.0.5 i 49.0.0–49.0.2 panikuje, gdy host odczytuje strumień modelu komponentów jako inny typ elementu Rust niż ten, z którym został utworzony, ponieważ ścieżka odczytu host-do-host sprawdza zgodność TypeId zamiast zwracać błąd. Kod gościa może zwrócić utworzony przez hosta StreamReader<U>, który embedder odczytuje jako StreamReader<T>, gdzie oba typy mapują się na ten sam typ modelu komponentów, powodując crash procesu.

Wasmtime w wersjach przed 36.0.18, 37.0.0–48.0.5 i 49.0.0–49.0.2 ogranicza tabele uchwytów zasobów modelu komponentów tylko na poziomie instancji komponentu i nie nalicza alokacji uchwytów do ResourceLimiter ani StoreLimits. Złośliwy gość może wielokrotnie wywoływać resource.new i tworzyć podkomponenty, aby wielokrotnie przekroczyć limit na instancję, powodując nieograniczony wzrost pamięci hosta.

Wasmtime w wersjach 47.0.0 przed 48.0.6 oraz 49.0.0 przed 49.0.3 zawiera błąd niewyrównania pamięci w układzie VMContext, który powoduje niezdefiniowane zachowanie, gdy moduły zawierają nieparzystą liczbę tagów wyjątków. Moduł WebAssembly z nieparzystą liczbą tagów powoduje niewyrównanie kolejnych pól hosta w embedderach z włączonymi wyjątkami, choć obecnie nie jest znana ścieżka eksploatacji.

Wasmtime od 49.0.0 do 49.0.2 zawiera podatność typu denial of service, która pozwala gościowi WebAssembly wywołać panikę hosta poprzez transkodowanie nakładających się łańcuchów w fused adapters. Atakujący może wykonać wywołanie komponent-do-komponentu w tej samej instancji, przenosząc łańcuch, którego źródło i cel nakładają się, powodując crash hosta zamiast trapa.

Wasmtime w wersjach 46.0.0–48.0.5 i 49.0.0–49.0.2 zawiera podatność typu denial of service w wasmtime-wasi-http, która pozwala gościom na crash hosta poprzez wysyłanie długich adresów URL żądań. Goście mogą użyć set-path-with-query z '?' po bajcie 65535, przepełniając indeks u16 w crate http i wywołując panikę hosta.

Wasmtime przed 36.0.18, 37.0.0 przed 48.0.6 oraz 49.0.0 przed 49.0.3 nie weryfikuje, czy wartości set-path-with-query w wasmtime-wasi-http są ścieżkami, więc adresy URL w formie absolutnej są zapisywane dosłownie jako cel żądania HTTP/1.1, podczas gdy połączenie używa dozwolonego authority. Złośliwy gość może podać absolutny URL, który proxy forward lub brama przy tym authority zaakceptuje, docierając do hostów zabronionych przez polityki filtrowania embeddera.

wasmtime-wasi w Wasmtime przed 36.0.18, 37.0.0 przed 48.0.6 oraz 49.0.0 przed 49.0.3 ponownie dodaje końcowy ukośnik do ścieżek źródłowych operacji rename, co powoduje, że renameat na hostach macOS i FreeBSD podąża za dowiązaniami symbolicznymi katalogów. Gość z prawem zapisu w piaskownicy może zmienić nazwę względnego dowiązania symbolicznego, takiego jak "up/", aby przenieść katalogi hosta do swojej piaskownicy i je odczytać lub zapisać.

Wasmtime od wersji 46.0.0 do 48.0.7 i 49.0.4 przy obniżaniu utworzonego przez hosta strumienia lub future modelu komponentów do gościa może pominąć wymaganą kontrolę typu ładunku po przejściu wartości przez kod gościa i powrocie przez StreamAny, FutureAny, Val::Stream, Val::Future lub równoważny czytnik typowany; złośliwy gość może spowodować panikę hosta Wasmtime.

Wasmtime w wersjach przed 24.0.12, 25.0.0 przed 36.0.13, 37.0.0 przed 46.0.2 oraz 47.0.0 przed 47.0.3 zawiera podatność na mylenie typów, ponieważ kilka API Store nie sprawdza, czy obiekty należą do Engine danego Store. Osadnicy mieszający obiekty między Engine'ami za pomocą Instance::new, StructRefPre::new lub Tag::new mogą wywołać niezgodności sygnatur trampolin, powodując zapisy poza granicami stosu, uszkodzenie sterty GC lub paniki.

W Wasmtime w wersjach przed 24.0.13, 25.0.0–36.0.14, 37.0.0–46.0.3 oraz 47.0.0–47.0.4 występuje ucieczka z piaskownicy systemu plików w wasmtime-wasi. Zależność cap-std nieprawidłowo obsługuje dowiązania symboliczne z końcowym ukośnikiem na macOS oraz na jądrach Linux bez openat2.

Wasmtime 46.0.0 przed 46.0.3 oraz 47.0.0 przed 47.0.4 zawiera podatność niekontrolowanej alokacji zasobów w implementacji WASIp3, która buforuje na hoście zapisy o długości określonej przez gościa bez limitu. Złośliwi goście mogą oferować duże bufory do strumieni zapisu plików lub HTTP WASIp3, powodując kopiowanie i buforowanie wszystkich bajtów przez hosta, ograniczone jedynie pamięcią liniową gościa, co wyczerpuje pamięć hosta.

Wasmtime 47.0.0 przed 48.0.3 oraz 49.0.0 przed 49.0.1 zawiera błąd rozliczania paliwa w ścieżkach call_ref i try_table catch kompilowanych przez Cranelift. Złośliwi goście mogą resetować zużyte paliwo po wywołaniach, aby działać wykładniczo długo przy liniowym paliwie, omijając limity czasu i okresowe ustępowania, co prowadzi do odmowy usługi.

Wasmtime w wersjach przed 36.0.16, 37.0.0–48.0.3 oraz 49.0.0–49.0.1 nie uwzględnia odpowiednio alokacji hosta podczas podnoszenia wartości gościa przez dynamicznie typowane API Val, omijając limit paliwa hostcall. Złośliwy gość WebAssembly może zwrócić spreparowane wartości alokujące co najmniej ~100x więcej pamięci hosta niż śledzone, powodując odmowę usługi.

W wasmtime-wasi-http w Wasmtime nie jest egzekwowany limit check-write dla wychodzących ciał HTTP w WASIp2, więc zbyt duże zapisy kończą się sukcesem zamiast pułapki. Złośliwy gość może przekazywać duże bufory do zapisu na zasobach wychodzącego ciała, utrzymując alokacje hosta przez czas życia store i wyczerpując pamięć hosta.

W Wasmtime w wasmtime-wasi istnieje luka umożliwiająca programom gościa WASI wywołanie paniki hosta poprzez przepełnienie znaczników czasu systemu plików. Atakujący mogą przekazać wartości atim lub mtim, których pole podsekundowe przepełnia pole sekund, do path_filestat_set_times, fd_filestat_set_times, set-times lub set-times-at, powodując awarię hosta.

Wasmtime w wersjach przed 36.0.17, 37.0.0–48.0.4 oraz 49.0.0–49.0.2 zawiera podatność na ujawnienie informacji w implementacji WASIp1 fd_readdir, która kopiuje niezainicjalizowane wypełnienie struktury do pamięci gościa. Goście z preotwartym katalogiem mogą listować wpisy, otrzymując trzy bajty pozostałej pamięci stosu lub sterty hosta na wpis katalogu.

W Wasmtime w implementacji WASIp3 w wasmtime-wasi istnieje luka umożliwiająca gościom przerwanie procesu hosta Unix. Goście z dostępem do zapisywalnego wstępnie otwartego katalogu mogą wywołać set-times lub set-times-at z ujemnymi znacznikami czasu przed epoką, wywołując błąd asercji i awarię hosta.

W Wasmtime istnieje luka niewłaściwej walidacji, która akceptuje komponenty, których moduły rdzeniowe importują tagi WebAssembly z podtypem oryginalnego typu. Złośliwi goście mogą błędnie typować ładunki obiektów wyjątków, uszkadzając stertę GC i powodując panikę Wasmtime, gdy włączona jest propozycja wyjątków.

W Wasmtime w implementacji wasi:http istnieje luka umożliwiająca gościom wywołanie paniki hosta. Goście mogą ustawić opcję żądania between-bytes-timeout na zero, co jest przekazywane bezpośrednio do API Tokio, które panikuje, powodując awarię osadzającego hosta.

W Wasmtime w metodzie write-zeroes w WASIp2 SinkOutputStream w wasmtime-wasi występuje nieograniczona alokacja pamięci. Złośliwy gość WebAssembly może żądać ogromnych zapisów wypełnionych zerami, wyczerpując pamięć hosta i powodując odmowę usługi.

W Wasmtime w adapterze poll_oneoff WASI preview 0 w wasmtime-wasi występuje luka odmowy usługi polegająca na wykonywaniu pracy O(n) na subskrypcję bez zużywania lub sprawdzania paliwa. Złośliwe moduły gościa mogą przekazać wiele subskrypcji, wymuszając długotrwałe obliczenia hosta ignorujące skonfigurowane limity paliwa.

W Wasmtime występuje luka braku zakotwiczenia GC, która pozostawia referencje żywe w poprzek try_call bez zakotwiczenia podczas kompilacji modułów Wasm. Atakujący mogą dostarczyć moduły Wasm, których wywoływany kod wyzwala odśmiecanie, pozostawiając nieaktualne lub wiszące referencje powodujące uszkodzenie sterty GC lub nieprawidłowe wykonanie.

Wasmtime to środowisko uruchomieniowe dla WebAssembly. Od wersji 46.0.0 do 46.0.2 i 47.0.3 sprawdzenia preempcji fuel i epoch wewnątrz operacji zbiorczych, w tym memory.copy, table.grow i array.copy, mogą ujawnić nieprawidłowy stan pośredni, gdy embedder modyfikuje Store w Store::epoch_deadline_callback lub kontynuuje używanie Store po anulowaniu lub trapie. Może to skutkować awarią, nieprawidłowym dostępem do pamięci lub uszkodzeniem sterty GC.

Wasmtime to środowisko uruchomieniowe dla WebAssembly. Przed wersjami 24.0.11, 36.0.12, 45.0.3 i 46.0.1, komponent wasmtime-wasi podczas tworzenia twardych dowiązań i zmiany nazw sprawdzał uprawnienia katalogów, ale nie uwzględniał uprawnień FilePerms dla źródłowych i docelowych preopenów. Umożliwiało to gościowi WASI z uprawnieniami tylko do odczytu źródłowego pliku nadpisanie plików hosta udostępnionych jako FilePerms::READ przez interfejsy systemów plików wasip1, wasip2 lub wasip3.

Wasmtime do wersji 24.0.10, 36.0.11, 44.0.3 oraz 45.0.2 zawiera podatność w natywnej implementacji WASIp1, gdzie funkcja fd_renumber nie zamyka prawidłowo deskryptora pliku, do którego następuje przepisanie. Powoduje to wyciek zasobów w systemie gospodarza, który może prowadzić do wyczerpania dostępnych deskryptorów plików i zasobów.

Wasmtime, środowisko uruchomieniowe dla WebAssembly, ma lukę w wersjach przed 24.0.9, 36.0.10 i 44.0.2, która pozwala na obejście mechanizmu kontroli dostępu przy użyciu interfejsów wasip2 descriptor.open-at lub wasip1 path_open. Problem wynika z braku odpowiedniego ustawienia trybu otwarcia, co umożliwia otwarcie pliku z flagą OpenFlags::TRUNCATE bez odpowiednich uprawnień do zapisu.

Wasmtime od wersji 30.0.0 do 36.0.8, 43.0.2 i 44.0.1 zawiera podatność na panikę przy alokacji bardzo dużych tablic WebAssembly. Problem wynika z arytmetyki sprawdzającej przepełnienie, która powoduje panikę przy próbie utworzenia tablicy o rozmiarze 64-bitowym (zgodnym z propozycją memory64). Atakujący może wywołać panikę poprzez dostarczenie modułu lub komponentu WebAssembly z żądaniem utworzenia ekstremalnie dużej tablicy.

W Wasmtime przed wersjami 24.0.7, 36.0.7, 42.0.2 i 43.0.1 implementacja transkodowania ciągów znaków między komponentami nie waliduje wartości zwracanej przez realloc gościa przed zapisem przez wskaźnik. Pozwala to gościowi spowodować zapis dowolnych bajtów transkodowanego ciągu w dowolne miejsce do 4 GiB od bazy pamięci liniowej, co może prowadzić do trafienia w niezmapowaną pamięć lub uszkodzenia struktur danych hosta.

Podatność w backendzie kompilatora Winch w Wasmtime (wersje 25.0.0 do przed 36.0.7, 42.0.2 i 43.0.1) polega na błędnym typowaniu wyniku operatora table.grow. Dla tabel 32-bitowych wynik jest wewnętrznie oznaczany jako 64-bitowy, co prowadzi do błędów w stanie kompilatora i może powodować odczyt/zapis do 16 bajtów przed pamięcią liniową. Domyślna konfiguracja Wasmtime (kompilator Cranelift, strony strażnicze) nie jest podatna; problem występuje przy jawnym wyborze Winch.

Podatność w Wasmtime (wersje 28.0.0 do przed 36.0.7, 42.0.2 i 43.0.1) w implementacji alokatora pooling polega na błędnym sprawdzaniu konieczności resetowania uprawnień pamięci wirtualnej dla pamięci liniowej. W wyniku rozbieżności między predykatami używanymi przy kompilacji i w czasie wykonania, w określonych konfiguracjach (memory_guard_size=0, memory_reservation < 4GiB, max_memory_size równy memory_reservation) dochodzi do wycieku zawartości pamięci liniowej między instancjami. Narusza to semantykę WebAssembly i piaskownicę Wasmtime.

W Wasmtime w wersji 43.0.0 klonowanie obiektu wasmtime::Linker jest niezgodne z zasadami bezpieczeństwa pamięci i może prowadzić do błędu use-after-free. Błąd nie jest kontrolowalny przez programy Wasm gościa — może go wywołać jedynie określona sekwencja wywołań API przez hosta: sklonowanie Linkera, usunięcie oryginału i użycie klonu. Podatność naprawiono w wersji 43.0.1.

Wasmtime w wersjach od 32.0.0 do 36.0.7, 42.0.2 i 43.0.1 zawiera błąd w kompilatorze Cranelift na architekturze aarch64, który powoduje nieprawidłowe obliczanie adresów pamięci przy dostępie do sterty. Błąd umożliwia modułom WebAssembly ominięcie kontroli granic i uzyskanie dostępu do dowolnej pamięci hosta, co prowadzi do ucieczki z piaskownicy.

W kompilatorze Winch w Wasmtime występuje błąd indeksowania tabel przy kompilacji instrukcji table.fill, spowodowany historycznym refaktoringiem, który nie zaktualizował ścieżek kodu Winch. Poprawny gość może spowodować panikę hosta lub modyfikację niewłaściwej tabeli. Podatność naprawiono w wersjach 36.0.7, 42.0.2 i 43.0.1.

Wasmtime w wersjach od 25.0.0 do przed 36.0.7, 42.0.2 i 43.0.1 zawiera błąd w kompilatorze Winch, gdzie 64-bitowa tablica (część propozycji memory64) niepoprawnie tłumaczy instrukcję table.size. Błąd może prowadzić do ujawnienia danych ze stosu hosta gościom WebAssembly. Przyczyną jest statyczne typowanie wartości zwracanej table.size jako 32-bitowej liczby całkowitej zamiast sprawdzania typu indeksu tablicy.

Wasmtime, środowisko uruchomieniowe WebAssembly, w wersjach przed 24.0.7, 36.0.7, 42.0.2 i 43.0.1 na platformach x86-64 z wyłączonym SSE3 może podczas kompilacji instrukcji f64x2.splat z Cranelift wczytać o 8 bajtów więcej niż potrzeba. Przy wyłączonych pułapkach opartych na sygnałach może to powodować nieprzechwycony segfault, a przy wyłączonych stronach strażniczych możliwe jest wczytanie danych spoza sandboxa (niewidocznych dla gości WebAssembly).

W Wasmtime w wersjach przed 24.0.7, 36.0.7, 42.0.2 i 43.0.1 implementacja transkodowania ciągów znaków do kodowań utf16 lub latin1+utf16 modelu komponentów nieprawidłowo weryfikowała wyrównanie realokowanych ciągów. Nie wyrównane wskaźniki mogły być przekazane do hosta, wywołując panikę hosta, którą złośliwy gość może wywołać celowo.

Wasmtime zawiera błąd walidacji długości bajtów podczas transkodowania ciągu UTF-16 do kodowania latin1+utf16 modelu komponentów. Sprawdzana jest liczba jednostek kodu zamiast długości w bajtach, co może prowadzić do odczytu poza końcem pamięci liniowej WebAssembly. W domyślnej konfiguracji powoduje to segfault (odmowa usługi), a przy wyłączonych stronach strażnika może umożliwić odczyt pamięci hosta.

W Wasmtime, środowisku uruchomieniowym WebAssembly, w wersjach przed 38.0.4, 37.0.3, 36.0.3 i 24.0.5 występuje niepoprawna interakcja w API dla osadzających w Rust. Współdzielona pamięć liniowa WebAssembly mogła być traktowana jako typ zapewniający bezpieczny dostęp hosta do jej zawartości, co przy równoległych modyfikacjach prowadzi do wyścigu danych w hoście.