и AMD

Искал это в тексте и нашёл. Учитывая, кто искал дыру, цель очевидна.

цель очевидна.

Заговоры повсюду.

Кучно пошли. Видимо опять предновогодний Humble Bundle.

Ну наконец-то

А в своих они не искали? Или их паверы волшебным образом недырявы?

Лорчую. Один производитель процессоров копает под другого. А страдают обычные пользователи.

Искал это в тексте и нашёл.

А я нашёл. Могу научить пользоваться поиском. Мастер-классы платные.

дырявы

Так там причина одинаковая что на Intel, что на AMD. Что на ARM. Домашнее задание: а на Power 9 ее нет.

https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

Лучше сначала научись читать. :) А то поубегают с уроков — и давай учить других поисковиками пользоваться...

«All of these identified vulnerabilities are variants of the same class of attacks but differ in the way that speculative execution is exploited.» Ой, гевалт! Спасибо, не знал.

Процессоры ломают яваскриптом!

А есть где-нибудь не описание, а хотя бы примерно работающий PoC для браузера?

Новый метод был успешно протестирован на процессорах Intel Haswell, Skylake и AMD Ryzen

Эльбрус рулит? ;)

Процессоры ломают яваскриптом!

Удваиваю.

И что, новые ожидаемые процы с аппаратным исправлением уязвимостей уже стали бесполезны?

неволшебным, но не дырявы.

Эльбруса опять нет в списке?

Так и представляю, как какеры всего мира денно и нощно стараются найти уязвимости в поделке, которой выпущено наверное меньше (нескольких) тыщ штук.

Зато безопасно!

Даже те аппаратные исправления целиком не чинят дыру, только слегка её прикрывают. Плюс есть ещё SMT/HT, которые тоже надо чинить. Реально надо вообще всю логику работы перелопачивать или серьезно так упрощать процессоры до состояния RISC-V.

Зато шовместимость!

За Эльбрус будущее мировой безопасности!

у эльбруса только явная спекулятивность и изолированные регистры.. не будет его в этом списке.

Эльбрус рулит? ;)

Оно разве не x86? Или там спекулятивное выполнение по просту не завезли?

Эльбруса опять нет в списке?

Какая досада.

да просто надо на Rust эти intel-firmware и amd64-firmware переписать))

Оно разве не x86?

Внезапно, нет.

спекуляции на power9 нет, что-то я сомневаюсь..

Эльбрус рулит? ;)

Да. и 286 sx.

А что если под транслятором оно проявляется? Наверняка в трансляторе есть спекулятивное выполнение, это же VLIW

Будто ты сейчас, в домашних условиях, взломаешь так комп Васяна по парте :)

и cyrix

у эльбруса только явная спекулятивность и изолированные регистры.. не будет его в этом списке.

ну и что с того что она «явная» — хочешь сказать что говнокомпилятор Эльбруса якобы не навставляет этих спекулятивностей в явном виде? прям в машинных кодах.

«явная» это же НЕ синоним слову «отсутствует». разве не так? :-)

// P.S.: Эльбрусами проблема скорее в том что SpiderMonkey там наверное ещё врядли дорос до JiT :-) — скорее всего именно это его и спасёт в случае с Браузером

А что от операционной системы в которой запускается jscript не зависит возможность эксплуатации уязвимости?

Оч. странно. Что за ОС пошли такие, что не изолируют hardware от прикладного кода?

Это что MS-DOS 21-го века?

а spectre v1 ни кто ранее и не обещал исправлять :-)

И что, новые ожидаемые процы с аппаратным исправлением уязвимостей уже стали бесполезны?

ни произволители процессоров НЕ обещали исправить.

ни в ядре операционной системе НЕ исправляли (кроме случая когда угроза взлома самого ядра — вот только это исправили. остальное — НЕ).

жёлтая пресса рассказывается только сказки о том что spectre v1 якобы исправится если якобы перекомпилировать софт новой версией компилятора (новой версией Microsoft Visual Studio.. а про GCC ничего такого опять-таки не обащели)

// P.S.: производители браузера поисправляли различные варианты spectre (в том числе v1) внутри себя — но как насчёт остальных программ которые могут иметь дела с внешними данными?

ну и что с того что она «явная» — хочешь сказать что говнокомпилятор Эльбруса якобы не навставляет этих спекулятивностей в явном виде? прям в машинных кодах.

Спекулятивность то есть, но как ее эксплуатировать?

SpiderMonkey там наверное ещё врядли дорос до JiT

Уже https://youtu.be/vbhA_FEL4kY

Убунтоводам можно не беспокоиться? - https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

и cyrix

Когда я его покупал , на нём таки было написано IBM

Ну да, в том и прикол. Секурити мартышки наяривали на секурность, пока индеец орлиный глаз не заметил, что целая стена-то отсутствует.

Тут круче. Тут можно не васяна ломануть, а целые корпорации. Фейсбуки и гугли ручным мартышечьим трудом может и выносят сор из избы, но десятки тысяч компаний даже не знают о таких дырах и светят наружу всем чем ни попадя.

Эльбруса опять нет в списке?

В Эльбрусе нет АНБшной закладки, извини.

Наверняка в трансляторе есть спекулятивное выполнение, это же VLIW

Транслятор это софт, а у VLIW есть только спекулятивный режим исполнения инструкций что в сочетании с софтом и дает спекулятивное исполнение как в интеле и амд.

А так то вообще spectre на эльбрусе то же возможен.

Но у них есть возможность просто подождать пока интел с amd придумают решение и сделать аналогичное в софте.

И мы снова видим призрачные очертания других кусков памяти приложения

IBM представила браузерный упрощенный вариант атаки Spectre v1

Как раз браузерный вариант они и не представили. Только теория, не сработавшая на практике в их же проверке (см.ниже).

Как пояснили исследователи, данная атака технически увеличивает длину окна спекулятивного выполнения.

Не вижу отличий от общеизвестной атаки. Просто небольшая вариация: считывание второго «доступного» массива делается снаружи от ветвления, а не внутри.

В остальном идея та же: при откате спекулятивных инструкций остаются изменения в кеше, которые можно обнаружить, замеряя время чтения переменной (из кеша читается быстрее, чем из обычной памяти). И тот же метод исправления: при откате спекулятивных инструкций процессор не должен оставлять изменения в кеше.

Можно было бы сказать, что таким методом можно доставать данные ядра, подставляя считывание регистров после системного вызова... Но нет, они проверили:

Speculative execution across system calls

a system call effectively stops speculative execution: it stops after the system call returns from kernel mode. We further conclude that SplitSpectre attack across the system call boundary is not feasible on the tested Intel CPUs.

Остаётся обычное доставание памяти одним куском приложения из другого куска этого же приложения. Да, это позволяет встраиваемым языкам типа javascript читать куски памяти браузера, которые должны быть недоступны (например, порнхаб может теоретически считать пароль и кукисы gmail-а из соседней вкладки). Но... в этом нет ничего нового, это всё тот же Spectre, про это все знают и, кто мог, это исправил.

И, да, это они тоже проверили, там их «новая» атака тоже не работает:

SplitSpectre in SpiderMonkey

JIT engine authors have already reacted with countermeasures [41], [11] in order to mitigate Spectre V1 in the context of browsers. These countermeasures [...] mitigate this version of JavaScript SplitSpectre.

PS: по-моему это обычная мелкая исследовательская работа, типа: «Мы тоже поисследовали ваши атаки, разработали очень крутую утилиту, и упомянули её в нашей работе всего лишь 25 раз. В общем, мы тоже есть, мы очень умные, не забывайте про нас!»

В нем только ФСБ-шные. В компиляторе — именно поэтому он проприетарный, и ни gcc-backend, ни llvm-backend для ЭльБруса не будет создан, ведь МЦСТ не нужен опенсорсный, свободный от закладок, компилятор для их проца, ну а сообществу нафиг не нужен ЭльБрус.

Транслятор это софт, а у VLIW есть только спекулятивный режим исполнения инструкций что в сочетании с софтом и дает спекулятивное исполнение как в интеле и амд.

Само по себе спекулятивное исполнение не ведет к уязвимости тут еще нужен аппаратный планировщик и предсказатель ветвлений, а их в Эльбрусе нет.

А Croco говорил про тьюринг-полный JS в браузере и его опасность. Вот теперь заживём!

спасёт его изоляция регистров( собственно это ключевая дыра для спектров) и то что компилятор эльбруса разворачивает спекулятивность контролируемым образом а не с помощью непредсказуемого кусочка кода в фирмвари который полагается на предположения вместо конкретных инструкций что нужно паралелить, а что нельзя.. это конечно оставляет нам простор для других принципиально новых уязвимостей от которых х86 будет возможно защищён, но в эльбрусе это будет софтовая бага..

JIT на эльбрусе такто уже есть, хоть и раз в 10 медленнее чем на х86( хотя может там за год ещё накрутили оптимизаций не слежу за прогрессом) но с этими эксплойтами он нам не поможет.

этот эксплойт как и предыдущая более медленная версия его уже закрыта заплатками.. вот эту новую версию следует воспринимать только как тычок необновляторам которые да не буду я патчить ничегону чо там с такой скоростью украсть можно? да за это время проще биткоинов намайнить.. а тут оказывается что можно и побыстрее данные тырить и уже не так неуловимо себя чуствует джо..