Кампанія Google апублікавала некалькі прататыпаў эксплоітаў, якія паказваюць магчымасць эксплуатацыі ўразлівасцяў класа Spectre пры выкананні JavaScript-кода ў браўзэры ў абыход раней дададзеных метадаў абароны. Эксплоіты могуць выкарыстоўвацца для атрымання доступу да памяці працэсу, які выконвае апрацоўку web-кантэнту ў бягучай укладцы. Для тэставання працы эксплоіта запушчаны сайт leaky.page, а код з апісаннем логікі праца размешчана на GitHub.
Прапанаваны прататып разлічаны на здзяйсненне нападу на сістэмы з працэсарамі Intel Core i7-6500U у асяроддзі з Linux і Chrome 88. Для ўжывання эксплоіта для іншых асяродкаў патрабуецца занясенне змен. Метад эксплуатацыі не спецыфічны для працэсараў Intel – пасля адпаведнай адаптацыі была пацверджана праца эксплоіта на сістэмах з CPU іншых вытворцаў, уключаючы Apple M1 на базе архітэктуры ARM. Пасля малаважных карэкціровак эксплоит таксама працаздольны ў іншых аперацыйных сістэмах і ў іншых браўзэрах на базе рухавічка Chromium.
У асяроддзі на базе штатнага Chrome 88 і працэсараў Intel Skylake атрымалася дамагчыся ўцечкі дадзеных з працэсу, які адказвае за апрацоўку web-кантэнту ў бягучай укладцы Chrome (renderer process), з хуткасцю 1 кілабайт у секунду. Дадаткова былі распрацаваны альтэрнатыўныя прататыпы, напрыклад, эксплоіт, які дазваляе коштам памяншэння стабільнасці павысіць хуткасць уцечкі да 8kB/s пры выкарыстанні таймера performance.now() з дакладнасцю 5 мікрасекунд (0.005 мілісекунд). Таксама быў падрыхтаваны варыянт, які працуе пры дакладнасці таймера на ўзроўні адной мілісекунды, які мог выкарыстоўвацца для арганізацыі доступу да памяці іншага працэсу са хуткасцю каля 60 байт у секунду.
Апублікаваны дэманстрацыйны код складаецца з трох частак. Першая частка выконвае каліброўку таймера для адзнакі часу выкананні аперацый, неабходных для ўзнаўлення дадзеных, якія засталіся ў працэсарным кэшы ў выніку спекулятыўнага выканання інструкцый CPU. Другая частка вырабляе азначэнне раскладкі памяці, выкарыстоўванай пры размяшчэнні масіва JavaScript.
Трэцяя частка непасрэдна выконвае эксплуатацыю ўразлівасці Spectre для вызначэння змесціва памяці бягучага працэсу ў выніку стварэння ўмоў для спекулятыўнага выканання вызначаных аперацый, вынік якіх адкідаецца працэсарам пасля вызначэння няўдалага прагнозу, але сляды выканання асядаюць у агульным кэшы і могуць быць адноўлены пры дапамозе метадаў вызначэння змесціва кэша па іншым каналам, якія аналізуюць змену часу доступу да пракэшаваных і не пракэшаваных дадзеных.
Прапанаваная тэхніка эксплуатацыі дазваляе абыйсціся без высокадакладных таймераў, даступных праз API performance.now(), і без падтрымкі тыпу SharedArrayBuffer, які дазваляе ствараць масівы ў падзялянай памяці. Эксплоіт уключае ў сябе гаджэт Spectre, які выклікае кантраляванае спекулятыўнае выкананне кода, і аналізатар уцечкі па іншых каналах, вызначальны якія патрапілі ў кэш дадзеныя, атрыманыя падчас спекулятыўнага выканання.
Гаджэт рэалізаваны пры дапамозе масіва JavaScript, у якім прадпрымаецца спроба доступу да вобласці па-за межамі буфера, якая ўплывае на стан блока прадказанні пераходаў з-за наяўнасці дададзенай кампілятарам праверкі памеру буфера (працэсар забягаючы наперад спекулятыўна выконвае зварот, але адкочвае стан пасля праверкі). Для аналізу змесціва кэша ва ўмовах недастатковай дакладнасці таймера прапанаваны метад, які падманвае якая ўжываецца ў працэсарах стратэгію выцяснення дадзеных з кэша Tree-PLRU і які дазваляе за кошт павелічэння ліку цыклаў значна павялічыць розніцу ў часе пры аддачы значэння з кэша і пры адсутнасці значэння ў кэшы.
Адзначаецца, што кампанія Google апублікавала прататып эксплоіта для таго каб паказаць рэалістычнасць нападаў з выкарыстаннем уразлівасцяў класа Spectre і для стымулявання web-распрацоўнікаў для ўжывання тэхнік, якія мінімізуюць рызыкі ад падобных нападаў. Пры гэтым Google лічыць, што без істотнай перапрацоўкі прапанаванага прататыпа немагчыма стварыць універсальныя эксплоіты, гатовыя не толькі для дэманстрацыі, але і для паўсюднага прымянення.
Для зніжэння рызыкі ўладальнікам сайтаў прапануецца выкарыстоўваць рэалізаваныя ў апошні час загалоўкі Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame-Options, X -Content-Type-Options і SameSite Cookie. Паказаныя механізмы напроста не абараняюць ад нападаў, але дазваляюць ізаляваць дадзеныя сайта ад уцечкі ў працэсы, у якіх можа быць выкананы JavaScript-код атакавалага (уцечка адбываецца з памяці бягучага працэсу, у якім апроч кода атакавалага могуць апрацоўвацца і дадзеныя іншага сайта, адчыненага ў той ж ўкладцы). Асноўная ідэя ў тым, каб падзяліць у розных працэсах выкананне кода сайта ад іншага кода, які атрымліваецца з ненадзейных крыніц, напрыклад, які ўключаецца праз iframe.
Крыніца: opennet.ru