LINUX.ORG.RU

Meltdown и Spectre — названия двух атак на процессоры Intel/AMD/ARM64/Power

 , , , ,


10

9

Разработчики из Google Project Zero опубликовали детали уязвимостей, которые затрагивают не только процессоры Intel и ARM64, но и AMD тоже (есть сообщения, что только при включении BPF JIT в ядре, что по умолчанию выключено). Названия им дали: Meltdown и Spectre (расплавление ядерного реактора и призрак).

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

Spectre создаёт брешь в изоляции различных приложений и позволяет атакующему обманным способом получить данные чужого приложения. Этой атаке подвержены процессоры Intel, AMD, ARM64, Power8 и 9. По неподтвержденным данным узявимы практически все процессоры, умеющие спекулятивное исполнение кода. Для Intel это процессоры, начиная с Pentium Pro (1995 год), кроме Itanium и Atom. Есть сообщения о том, что уязвимость проверена на Pentium-M 1.5 ГГц (2004 год).

Эксплоит, эксплуатирующий Meltdown позволяет читать память ядра со скоростью 2000 байт в секунду на процессоре Intel Xeon архитектуры Haswell.

Уязвимостям назначены следующие CVE: CVE-2017-5753, CVE-2017-5715 и CVE-2017-5754.

Напомню, что пользователи ежедневно запускают чужой код на своих компьютерах, посещая веб сайты с JavaScript (>99%), поэтому применение патча (здесь и здесь) обязательно, если вы дорожите своими данными. Есть PoC (п.4.3) , демонстрирующий атаку с этой уязвимостью через JavaScript.

Разработчики ARM приводят подробности атаки для ARM, заявляют о том, что уязвимы лишь некоторые процессоры ARM, дают их список и меры по повышению безопасности.

Технические подробности про spectre (есть пример кода в конце файла)
Код из spectre.pdf выложенный отдельно.
Технические подробности про meltdown
Еще про meltdown
Видео, демонстрирующее утечку памяти meltdown
Технические детали для ARM-процессоров
Отчёт от Red Hat, упоминающий процессоры IBM Power как уязвимые.

UPD: Хорошая статья на русском языке про meltdown
UPD2: Продолжение про два вида Spectre

>>> Подробности

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: hobbit (всего исправлений: 24)

Ответ на: комментарий от NextGenenration

Патч уже доступен. Так что нет

Какой, для ведра? Хомячок его не поставит пока слоупоки-мейнтейнеры не завезут его в репозитарий, да и после не факт. Так что да.

h578b1bde ★☆
()
Ответ на: комментарий от NextGenenration

Патч уже доступен. Так что нет

Но гарантий нет ни для ESR, ни для 'master'! %-)

https://twitter.com/aprilmpls/status/949314868200472576

ESR doesn't support the primary feature (SharedArrayBuffer) disabled in 57.0.4, although I wouldn't be surprised for there to be further mitigations as time goes along.

atsym ★★★★★
()
Ответ на: комментарий от anonymous

Теперь же, все, что было нажито непосильным трудом просрано в даунгрейд от 5% до 30% процентов.

Уже были бенчмарки, обычному юзеру пофиг, разница около нуля или пару процентов, а вот базы данных, IO, сети - тут да....

FiXer ★★☆☆☆
()
Ответ на: комментарий от FiXer

сети

Любители погонять в какие-нибудь шутеры оценят.

h578b1bde ★☆
()
Ответ на: комментарий от NextGenenration

Я изменил до максимума сообщений

Я не про это, я про то, что тут сообщений дохрена.

жаль больше нельзя

Не «жаль», а нехрен айфон Макскома нагружать.

bodqhrohro_promo
()
Ответ на: комментарий от FiXer

а вот базы данных, IO, сети

Обычный юзер ими не пользуется, что ли — играет в сапёра только и даже рекорды не сохраняет?

bodqhrohro_promo
()

JavaScript

нучо я могу сказать? слава жаба(скрипту)?
А вообще ленива патч накатывать. я б лучше исправления в браузере дождался или новой версии JS, если текущая так крива. мне пох, если 99,9% интернета у меня работать не будет, зато говноязыка не будет в браузере. Неужели нельзя было предложить нормальное решение в контейнерах или иных системах изоляции? Вы мне ещё после этого начните высер, что жабаскрипт не тормознутое,жручее, дырявое поделие и зависит от рук кодеров. ЯП, допускающий дырки через браузер, вообще имеет право существовать?

darkenshvein ★★★★★
()
Ответ на: комментарий от Valeg

"- Excuse me but Pale Moon is simply not vulnerable." © wolfbest, (Jan 6, 2017)

В Pale Moon уже начали какашками бросаться во всех неуверовавших в святость Pale Moon, LOL

https://github.com/MoonchildProductions/Pale-Moon/issues/1568#issuecomment-35...

https://github.com/MoonchildProductions/Pale-Moon/issues/1568#issuecomment-35...

Хотя, всплыло и то что разрабы Pale Moon знали об этой уязвимости год назад...

https://github.com/MoonchildProductions/Pale-Moon/issues/1568#issuecomment-35...

atsym ★★★★★
()
Последнее исправление: atsym (всего исправлений: 1)
Ответ на: комментарий от atsym

Запретить JavaScript в интернете - и баг уже не такой и критический был бы ;-)

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

darkenshvein ★★★★★
()
Ответ на: комментарий от darkenshvein

ЯП, допускающий дырки через браузер, вообще имеет право существовать?

Диванный аналитег, назови хоть один язык, реализация которого не может допускать уязвимости

NextGenenration ★★
()
Ответ на: комментарий от NextGenenration

Диванный аналитег, назови хоть один язык, реализация которого не может допускать уязвимости


сначала назови один нормальный вариант языка для веба.

darkenshvein ★★★★★
()
Ответ на: комментарий от NextGenenration

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

Латынь, очевидно же! ;-)

atsym ★★★★★
()
Последнее исправление: atsym (всего исправлений: 1)
Ответ на: комментарий от darkenshvein

сначала назови один нормальный вариант языка для веба.

99% проблем с которыми сталкиваются конечные пользователи связаны не с языком. Это программисты могут получить/потерять удобство.

NextGenenration ★★
()
Ответ на: комментарий от darkenshvein

кто с воплями энтузиазма продвигал выпук?

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

dogbert ★★★★★
()
Ответ на: комментарий от dzidzitop

Но точно окажусь в меньшинстве.

Если ты не считаешь Spectre уязвимостью - ты уже в меньшинстве. Хотя на твоей стороне аж целый Intel.

Песочницам нужно было выполняться в ring 2 с защищёнными страницами памяти, а managed code выполнять в ring 3

Серьезно? Хотя нет, я не хочу знать.

Может, сочинят на уровне набора команд процессоров какие-нибудь неспекулятивные джампы и ретурны, чтобы подпереть ими критические места.

Или будут ставить mfence перед вызовом таймера.

Т.е. решение одно - выполнять весь код одинаково медленно.

Этого, конечно, не будет. На крайний случай огрубят таймер.

tailgunner ★★★★★
()
Ответ на: комментарий от FiXer

Уже дали. Добавлю, что всё нужное написано в хедпосте.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Если ты не считаешь Spectre уязвимостью - ты уже в меньшинстве. Хотя на твоей стороне аж целый Intel.

и правильно считают, что криворукие си-кодеры пользоваться современным оборудованием не могут, не допуская проблем с безопасностью

wieker ★★
()
Последнее исправление: wieker (всего исправлений: 1)
Ответ на: комментарий от wieker

и правильно считают, что криворукие си-кодеры пользоваться современным оборудованием не могут, не допуская проблем с безопасностью

В данном случае язык имеет не такое большое значение.

NextGenenration ★★
()
Ответ на: комментарий от dzidzitop

в общем - всем программистам пофиг и сейчас должно быть на такие тайминг атаки кроме тех, кто придумывает мельдонии в своих процессорах или пишет сэндбоксы для изоляции кода

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

wieker ★★
()
Ответ на: комментарий от tailgunner

конечно в меньшинстве. а придурки эти уже начали компиляторы «исправлять», микрокод, патчить ядра, при том, что через управляемое вытеснение данных из кэша теоретически можно что угодно сделать. нужно кэш жесточайше запретить!!! хотя по итогу и кэш останется и придурки своими фиксами уронят производительность и хардвара и ядра и юзерспейса в ноль.

dzidzitop ★★
()
Ответ на: комментарий от wieker

уже заливают апдейты патчей микрокода и в компиляторах добровольно-принудительно по советам дебилов из гугла ретурнами вместо косвенных переходов обманывают spectre-2 с превосходным пенальти по перформансу. паника перешла в действия. маразм крепчает.

при этом, представляете, можно через радиоэфир теоретически передать информацию с уровнем полезного сигнала на 0.01дБ выше шумовой полки! никто никогда не дождётся этой информации, но нужно радиоэфир начинать радиоэфир засирать белым шумом силой сотни децибел, чтобы шпион не прошёл!

к слову, были когда-то разговоры о стоимости вызова виртуальных функций на плюсах. ловите +5 к стоимости из-за Спектре!

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 2)
Ответ на: комментарий от dzidzitop

будет забавно, если «фиксы» спектра упростят какой-либо другой тип тайминг атаки. и иронично.

wieker ★★
()
Последнее исправление: wieker (всего исправлений: 1)
Ответ на: комментарий от atsym

Для проверки возможности атаки

А это нуждается в проверке? Впрочем, ТНБ с ними.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

Но эти люди будут «патчить» компиляторы, чтобы каждая программа вместо нормальных инструкций процессора использовала fences или ретурны, а процессор будет распознавать это и добровольно-принудительно тормозить код. При этом возможность атаковать как была гипотетической - так и останется в такой же мере гипотетической. Только работать всё будет медленнее. Офигенное решение.

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

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

Дальше сильно проще не становится, так как нам надо теперь выяснить, что лежит в кэше — и положено оно туда от имени стороннего процесса, то есть, в отличие от Meltdown, напрямую пощупать память мы не можем.

Тем не менее, и тут могут найтись свои методы

могут найтись методы!!! охренеть. А может ещё дядя майор с паяльником придти и попросить обратиться спекулятивно к массиву по индексу минуя планировщик задач.

dzidzitop ★★
()

Хотя, всплыло и то что разрабы Pale Moon знали об этой уязвимости год назад

Как так? Они же, по версии лучших экспертов ЛОРа, васяны, не заслуживающие доверия и способные только этикетку на Файрфоксе перебивать? Шо, сюрприз?

LittleKawaiiNeko ★★
()
Ответ на: комментарий от tailgunner

а при чём тут ядра? данные в кэше изолированы, ибо адресуются по физическим адресам. Достаточно sleep(true_rand(10)) поставить - и содержимое кэша через атакуемую программу ты не прочитаешь никак (со статистически значимой гарантией).

Но могут же найтись методы! Пока не найдены и непонятно совершенно как они могут найтись, но ведь могут!

Вместо того, чтобы проверять и патчить libssl и прочую подобную инфраструктуру занимаются ерундой.

А ядра писать много ума не надо. А вот написать ядро, в котором чтоб при копировании через nfs асинхронно 50гигового файла по FastEthernet система колом не становилась - это уже потруднее. Пока не осилили. Зато gcc пропатчат, чтобы косвенная адресация вернулась во времена 80386 по стоимости. Ибо нефиг.

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

Ты, дядь, исходишь «не в ту сторону». Не то направления взял.

Deleted
()
Ответ на: комментарий от dzidzitop

Зато gcc пропатчат, чтобы косвенная адресация вернулась во времена 80386 по стоимости. Ибо нефиг.

Вот это круто, я на тройке несколько игрушек недопрошёл, а на эмулях играть совсем не то, а тут всё пропатчат, и досовские игры полетят как на родном железе!

Napilnik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.