Инженеры Microsoft и Google совместными усилиями обнаружили новую уязвимость в процессорах Intel, AMD, ARM похожую на Meltdown и Spectre. Угрозу назвали Speculative Store Bypass (v4) (CVE-2018-3639). Аналогично Spectre, эксплойт также использует спекулятивное выполнение команд, которое предоставляют современные CPU.
Метод атаки напоминает Spectre 1, но базируется на восстановлении осевших в процессорном кэше данных после отбрасывания результата спекулятивного выполнения операций при обработке чередующихся операций записи и чтения с использованием косвенной адресации. Когда операция чтения следует за операцией записи (например, mov [rbx + rcx], 0x0; mov rax, [rdx + rsi]), смещение адреса для чтения уже может быть известно из-за выполнения похожих операций (операции чтения выполняются значительно чаще и чтение может быть выполнено из кэша) и процессор может спекулятивно выполнить чтение раньше записи, не дожидаясь пока будет вычислено смещение косвенной адресации для записи. Если после вычисления смещения выявлено пересечение областей памяти для записи и чтения, процессор просто отбросит уже спекулятивно полученный результат чтения и повторит эту операцию.
Особенностью Speculative Store Bypass является возможность её использования с помощью скриптов внутри приложений. Другими словами, злоумышленники могут оставить вредоносный JavaScript-код прямо на веб-странице, а пользователь при её посещении тут же окажется в опасности. Хакеры могут получить доступ к данным, хранящимся в памяти браузера. Это может быть история поисковых запросов, адреса, данные банковских карт и прочее.
Однако, данная уязвимость была найдена в ноябре 2017 года, а Intel уже выкатила бета версии микрокода для OEM производителей чтобы те обновили свои продукты. Как и в случае Spectre и Meltdown приведет к потере производительности на 2 — 8%, по данным теста SYSmark 2014 SE. Апдейты пакетов с ядром собраны для RHEL и Ubuntu, и ожидаются для SUSE и Debian.
«Мы продолжаем работать с затронутыми производителями процессоров и уже предприняли более глубокие меры защиты для устранения уязвимостей вредоносного исполнения в наших продуктах и ??сервисах. Нам неизвестен какой-либо экземпляр, использующий этот эксплойт, который бы влиял на Windows или нашу инфраструктуру облачных сервисов. Мы стремимся к дальнейшему смягчению последствий для наших клиентов», — рассказал представитель Microsoft.
Комментарии (51)
Vitalley
22.05.2018 22:27+1Производительность новых процов еле растет, так давайте старые затормозим. Хороший маркетинговый ход, с далека зашли.
besitzeruf
23.05.2018 01:09+2Попробую намекнуть прямо — эти уязвимости относятся ко всем предыдущим поколениям, примерно за 10 лет…
Garbus
23.05.2018 03:43+1Так вообще замечательно! Даже старенькое железо, исправно крутящее простенькие задачки, менять придется. Это же какие продажи внезапно попрут.
Но вообще конечно не особо приятные новости для различных сервисов. Цены немного подрастут, а кто-то и вовсе закроется. Остается лишь надеяться, что патчи будут раньше крупных утечек данных.Psychosynthesis
23.05.2018 07:30Да не будет ничего. Уязвимость слишком трудно использовать и слишком дорого исправлять.
Garbus
23.05.2018 08:40Ой, да какой только фигней люди не страдают совершенно бесплатно. Что уж говорить при наличии финансового интереса. Если информация действительно ценная, принцип «неуловимого Джо» может и не сработать.
roscomtheend
23.05.2018 09:13«Старые и новые» вы хотели сказать. Отличный маркетинг — покупайте наши уязвимые процессоры, других всё равно нет.
Vitalley
23.05.2018 16:01Я же говорю, большой задел на будущее, сейчас будем потихоньку снижать производительность этих, а потом выйдут новые исправленные и их хорошо можно будет продавать.
firk
23.05.2018 02:39Скоро придётся им половину, если не больше, внутрипроцовых ускорителей исполнения убирать, ибо все они основываются на возможности сделать что-то заранее и имеют побочные эффекты на тайминги (ускорение же). И окажется что честно и без этих дыр можно работать на частоте не больше чем частота выборки из оперативной памяти (а это в лучшем случае сотни МГц). Ну ещё можно дать софту (или ОС) явную адресацию процессорного кеша как ещё одной области физической памяти, чтобы ОС, которая уже знает кого от кого надо защищать, сама клала в кеш нужные страницы по своему алгоритму. Это наверно будет медленнее чем сейчас (хотя в теории там можно сделать и более хороший алгоритм под конкретные нужды), но быстрее чем на частоте памяти.
venco
23.05.2018 11:20Достаточно сбрасывать спекулятивно загруженную строку кеша.
qw1
23.05.2018 16:33Недостаточно, потому что загруженная строка вытеснит другую строку, и вытесненную нужно будет восстановить. Иначе можно будет определить, какая строка вытеснена.
firk
24.05.2018 02:41Всё ещё хуже — неспекулятивный кеш тоже может что-то раскрыть про код, который его подгрузил. Хотя это эксплуатировать ещё сложнее чем то что имеется, но думаю найти подходящую ситуацию возможно. И закрыть это можно либо проверяя весь код на то, какие побочные эффекты на кеш он делает и насколько они вычислимы сторонним наблюдателем, либо переведя кеш на програмное управление.
qw1
24.05.2018 02:48Я предлагаю в стадию отката команды, когда обнаружена ошибка доступа, откатывать не только значения регистров, как сейчас происходит, но и состояния строк кеша. Для этого нужно завести пару-тройку «теневых» строк, которые будут подгружаться в спекулятивном выполнении, и коммититься в основной кеш, только если команда завершилась успешно.
Akon32
23.05.2018 12:09Зачем убирать? Достаточно добавить корректные проверки доступа.
qw1
23.05.2018 16:34Они есть. Проблема в том, что проверки доступа для ускорения выполняются параллельно с другими операциями. И, когда проверка говорит «нельзя», параллельные операции уже залезли в кеш.
Akon32
23.05.2018 16:47Не могу назвать эти проверки корректными, если инструкции меняют кэш на основе данных, доступ к которым запрещён.
qw1
23.05.2018 17:08Проверки сами по себе корректные, но выполнять их надо до запуска основной функциональности инструкции, а не параллельно с ней. Можно отменить конвеер и делать всё строго последовательно, а не брать в работу сразу по 10 инструкций и выполнять их как удобнее, т.е. out-of-order.
Sonatix
23.05.2018 09:25Там 10% потеряли, тут 8%. Это можно так допатчиться что пределом мечтаний станет запустить «сапера» или «косынку» на самом производительном процессоре.
N1ghtroad
23.05.2018 10:09+2Как бы на затычках не потеряли в скорости больше, чем даёт спекулятивное выполнение…
Да и вообще эти уязвимости кажутся мне настолько сложноюзабельными, а использование их настолько узконаправленным, что лучше бы было выпустить уже серию камней без "опасных" ускорителей для оборонки и параноиков, а в гражданском сегменте оставить всё как есть.Akon32
23.05.2018 12:14В гражданском сегменте есть банковские приложения, так что не следует считать, что безопасность не нужна.
Vitalley
23.05.2018 16:05Так на них левый софт не запускают же, а если кто-то и доберётся то ничего не поможет. Тут главная уязвимость — открыл страницу и яваскрипт тебя хакнул… вот это не приятно. С остальным можно бороться.
Akon32
23.05.2018 16:24Приложения банков для удалённого доступа к банковским услугам, вообще-то, запускаются на устройствах пользователей. В том числе и через web.
Те же самые устройства часто одновременно используются и для других вещей.
Думаю, не нужно объяснять, что разделение адресных пространств процессов — отличная штука, и почему без неё будет, мягко говоря, неудобно.
C_21
23.05.2018 11:20Отключать обновления или покупать новый камень? Через годик выкатят новые уязвимости и закроют их 50% производительностью камня, вот тогда будет весело.
alan008
23.05.2018 12:04По-моему вполне логично, что чем сложнее система, тем больше в ней дыр.
И это касается и железа, и ОС, и прикладного ПО.
— У нас дыра в безопасности!
— Ну хоть что-то у нас в безопасности.
JC_IIB
23.05.2018 12:11Найдена новая уязвимость в процессорах
Однако, данная уязвимость была найдена в ноябре 2017 года, а Intel уже выкатила бета версии микрокода для OEM производителей чтобы те обновили свои продукты.
Апдейты пакетов с ядром собраны для RHEL и Ubuntu
Дело Ализара живет.grvelvet Автор
23.05.2018 12:18Meltdown и Spectre были найдены в середине 2017, а патчи выкатили только в январе 2018, да и известно о них обществу стало примерно тогда же.
T-362
23.05.2018 12:42Такими темпами похоже что придется перейти на i7 просто потому-что с закрытием уязвимостей мощность серии упадет до уровня i5 (а сам i5 упадет до уровня кофемолки). Или вообще перейти на AMD.
springimport
23.05.2018 17:18Во времена когда трава была зеленее, где-то в 2012 году, удивлялся насколько 3770 быстр. Семерка загружалась за 10 секунд с hdd. Все остальное отрабатывало моментально.
И вот наступает 2018. Видео на Утубе переходит в полноэкранный режим за секунду (вместо сотен мс). Ощущение, как вы правильно описали, i5.sumanai
23.05.2018 22:34+2Вопросы к браузеру и ютубу, а не процессору. Ютуб тормозит, браузеры жиреют.
springimport
23.05.2018 22:46Да. Еще это будет означать что все остальные программы тоже стали работать медленнее.
stifff
23.05.2018 14:53А нет слухов, появятся ли вообще процессоры, в которых эти типы уязвимостей будут исправлены в железе?
catharsis
23.05.2018 16:48Объясните кто-нибудь пожалуйста, почему возможность точного тайминга операций важна для непривилегированных процессов?
qw1
23.05.2018 17:12Инструкция чтения текущего такта давно доступна, и неизвестно, что сломается, если поменять её поведение (хотя, если отключить её только у браузера, наверное не будет проблем).
Но, если точный таймер убрать, время можно набирать или тупо статистикой, или выполняя операции в цикле и используя обычные часы.
Другой вариант — запустить 2 потока, второй поток тупо крутит i++ в цикле и таким образом обеспечивает приличную точность.mwizard
23.05.2018 21:32+1Запретить циклы, потоки и инкременты!
a5b
24.05.2018 06:47Запретили таймер и общий буфер между потоками: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
starting with 57:
- The resolution of performance.now() will be reduced to 20µs. (UPDATE: see the MDN documentation for performance.now for up-to-date precision information.)
- The SharedArrayBuffer feature is being disabled by default.
https://gruss.cc/files/fantastictimers.pdf Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript (2017, doi:10.1007/978-3-319-70972-7_13) + https://gruss.cc/files/timers_slides.pdf
mwizard
24.05.2018 11:15Ну так не беда — просто это теперь займет больше времени, пока статистика наберется.
ktod
23.05.2018 18:04По-видимому, придется инженерам вводить новую сущность — свойство для нитей, которое отключает всю спекулярку и прочие потенциально опасные «ускорялки». Так сказать SecureThreadFlag. И для потенциально опасных приложений, типа браузера, это свойство устанавливать.
DmitriyN
24.05.2018 19:20Такое уже есть — аппаратные memory barriers. В x86 — это lfence/sfence.
qw1
24.05.2018 20:10Т.е. Chrome, когда JIT-тит js, должен после каждой инструкции добавлять LFENCE? Так он быстро вылетит из списка быстрых браузеров.
DmitriyN
24.05.2018 20:32Думаю, удар по производительности будет почти такой же, как и от отключения спекуляции специальным флагом (предлагалось ведь именно это). Все равно в такой ситуации, коду, генерируемому JIT вряд ли получится заполнить все issue слоты.
kasperos
24.05.2018 11:19На мой взгляд, вся истерия со Spectre и Meltdown это перекладывание с больной головы на здоровую:
-процессор меняет очередность выполнения в угоду производительности;
-в процессе выполнения оказывается что что нарушено право доступа к памяти;
-процессор генерирует исключительную ситуацию: «тут процесс не туда полез, посмотри»;
-операционная система приложению: «тут процессор говорит что ты не туда полез, на посмотри где ты лажанул» (а раньше приложения регулярно крашились с ошибкой доступа).
Проблема не в том что процессор проверяет право доступа после операции доступа (да хоть 3-4 инструкции пропустит, за это время зловред практически ничего не успеет сделать с парой байтов секретной информации), проблема в том что операционная система в угоду «стабильности» передает не глядя обработку опасного исключения: «самому приложению».
Это как охранник пустит человека который ломится в закрытую дверь: «подождите я вам сейчас открою, тут закрыто», лишь потому что за 30 лет его к этому приучили люди которые постоянно забывают свои ключи или путают двери.qw1
24.05.2018 14:40Хорошая защита от Meltdown — просто чистить кеши всех уровней при появлении исключения. Заодно говнокодеры, которые делают логику на exception-ах, задумаются.
Однако, от Spectre это не спасает. Когда процессор понимает, что он зашёл не в ту ветку из-за неверно предсказанного перехода, он откатывает регистры без уведомления ОС.
DrSavinkov
2% там, 3% здесь и вот — «Покупайте наши новые процессоры, они производительнее на 20% по сравнению с предыдущим поколением!».
dimonoid
Молодцы! Идут по стопам Apple. А что мне делать с моим ноутбуком на 6700k? Процессор без всего остального не поменять, сокет в 8700k другой, а в следующем поколении опять наверное изменят, да даже один только процессор не дешевый.
А есть где то сравнение скорости версий Windows 10 на одном и том же железе, типа 1803 vs 1703?