{"id":107183,"date":"2023-03-10T18:48:11","date_gmt":"2023-03-10T16:48:11","guid":{"rendered":"https:\/\/prohoster.info\/?p=107183"},"modified":"2023-03-13T12:06:39","modified_gmt":"2023-03-13T10:06:39","slug":"kriticheskaya-uyazvimost-v-wasmtime-runtime-dlya-webassembly-prilozhenij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/kriticheskaya-uyazvimost-v-wasmtime-runtime-dlya-webassembly-prilozhenij","title":{"rendered":"Kritische Sicherheitsanf\u00e4lligkeit in Wasmtime, dem Runtime f\u00fcr WebAssembly-Anwendungen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In den Korrektur-Updates Wasmtime 6.0.1, 5.0.1 und 4.0.1 wurde eine Schwachstelle (CVE-2023-26489) behoben, die als kritisch eingestuft ist. Diese Schwachstelle erm\u00f6glicht es, Daten in einen Speicherbereich au\u00dferhalb der f\u00fcr isolierten WebAssembly-Code zul\u00e4ssigen Grenzen zu schreiben, was potenziell von Angreifern genutzt werden k\u00f6nnte, um eigenen Code au\u00dferhalb der isolierten Umgebung von WASI auszuf\u00fchren. <\/p>\n
Wasmtime ist eine Laufzeitumgebung f\u00fcr die Ausf\u00fchrung von WebAssembly-Anwendungen mit WASI-Erweiterungen (WebAssembly System Interface) als herk\u00f6mmliche isolierte Anwendungen. Das Toolkit ist in Rust geschrieben, und die Schwachstelle wurde durch einen logischen Fehler bei der Festlegung der Regeln f\u00fcr die lineare Adressierung im Cranelift-Codegenerator verursacht, der eine hardwareunabh\u00e4ngige Zwischenrepr\u00e4sentation in ausf\u00fchrlichen Maschinencode f\u00fcr die Architektur x86_64 \u00fcbersetzt. <\/p>\n
F\u00fcr WebAssembly-Anwendungen wurden 35-Bit effektive Adressen berechnet, anstelle der in WebAssembly zul\u00e4ssigen 33-Bit-Adressen. Dies verschob die Grenze f\u00fcr zul\u00e4ssige Lese- und Schreiboperationen im virtuellen Speicher auf 34 GB, w\u00e4hrend die Sandbox-Einstellungen Schutz f\u00fcr 6 GB ab der Basisadresse bieten. Infolgedessen war der Bereich des virtuellen Speichers von 6 bis 34 GB ab der Basisadresse f\u00fcr Lese- und Schreibzugriffe aus WebAssembly-Anwendungen verf\u00fcgbar. In diesem Speicher k\u00f6nnen andere WebAssembly-Umgebungen oder Komponenten der WebAssembly-Laufzeit untergebracht werden. <\/p>\n
Wenn ein Upgrade der Wasmtime-Version nicht m\u00f6glich ist, wird als Workaround empfohlen, die Option \u201eConfig::static_memory_maximum_size(0)\u201c zu setzen, um eine separate \u00dcberpr\u00fcfung der Grenzen bei jedem Zugriff auf den linearen Speicher zu erzwingen (was die Leistung erheblich beeintr\u00e4chtigt). Eine andere M\u00f6glichkeit besteht darin, die Einstellung \u201eConfig::static_memory_guard_size(1 < 36)\u201c zu verwenden, um die Anzahl der Guard Pages (Schutzseiten) im problematischen Bereich des virtuellen Speichers zu erh\u00f6hen (bei Zugriff wird eine Ausnahme ausgel\u00f6st), was zu einer hohen Reservierung des virtuellen Speichers und einer Begrenzung der gleichzeitig ausgef\u00fchrten WebAssembly-Anwendungen f\u00fchrt. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"