& вместо |. Рассказываем, как крошечный баг в движке SpiderMonkey привел к критической уязвимости

Критическая уязвимость в движке SpiderMonkey возникла из-за опечатки в один символ. В коде сборщика мусора для WebAssembly разработчик поставил & вместо |. На вид мелочь, побитовое И вместо побитового ИЛИ, а на деле ломается метка. Вместо выставленного младшего бита в указателе переадресации в заголовок записывался ноль. Из-за этого сборщик мусора и оптимизирующий компилятор Ion начинали по-разному понимать, где лежат данные массива. Дальше открывался прямой путь к удаленному выполнению кода.

Механика такая. Когда GC переносит массив WebAssembly в другую область памяти, старый буфер должен получить указатель на новое место с выставленным младшим битом. Это сигнал для Ion. Но из-за & 1 вместо | 1 в заголовок попадал ноль, который еще и проходил проверку на встроенный массив. Ion продолжал ходить по старому адресу, хотя память уже освободили. Дальше все по учебнику для use-after-free: распыление кучи, перехват потока выполнения, запуск командной оболочки.

И отдельно пугает скорость. Ошибку внесли 19 января, а уже 3 февраля два независимых исследователя прислали отчеты с рабочими PoC. То есть баг появился, его нашли и довели до эксплуатации буквально за считанные дни. Повезло только в одном: проблема успела попасть лишь в Firefox 149 Nightly и не доехала до стабильных релизов.

#firefox #rce #webassembly