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

А всё началось куда заранее.

С июня 2017г. Google’s Project Zero.

Кстати там русские фамилии есть

Сейчас есть патчи от спектра или это все-таки принципиально архитектурная лажа и не латается?

Это принципиальная архитектурная. Можно ли ее залатать - никто пока точно не сказал, хотя лично мне кажется, что можно.

+ добавь ссылку на PoC Spectre

Там тот же код, что и в spectre.pdf думаешь всё-равно надо добавить, чтобы не выковыривали его?

Разработчики LLVM выкатили патчи для CVE-2017-5715

Чего-то это похоже не на патч, а на «подложили немного соломки».

Думаю, что будет минимум ещё одна новость с обзором патчей, переспектив на будущее, новых ядер и cpu и т.п. Там это уместнее. Сейчас не вижу большого смысла упоминать об этом патче в данной новости, так как минимум требуется перекомпиляция софта этим llvm.

https://reviews.llvm.org/D41723

там лор-эффект.

Собственно, вот с таким выводом беспокоиться или вероятность что меня прочтут низка (значение 30, если больше, то почти все ?):

$>> ./spectre 
Reading 40 bytes:
Reading at malicious_x = 0xffffffffffdfed68... Unclear: 0xDD=’?’ score=919 (second best: 0x9A score=919)
Reading at malicious_x = 0xffffffffffdfed69... Unclear: 0xA2=’?’ score=955 (second best: 0x49 score=943)
Reading at malicious_x = 0xffffffffffdfed6a... Unclear: 0xA2=’?’ score=936 (second best: 0x88 score=935)
Reading at malicious_x = 0xffffffffffdfed6b... Unclear: 0xFF=’?’ score=976 (second best: 0xE6 score=976)
Reading at malicious_x = 0xffffffffffdfed6c... Unclear: 0xA2=’?’ score=965 (second best: 0x6B score=965)
Reading at malicious_x = 0xffffffffffdfed6d... Unclear: 0x88=’?’ score=963 (second best: 0x3A score=960)
Reading at malicious_x = 0xffffffffffdfed6e... Unclear: 0x6B=’k’ score=968 (second best: 0xE1 score=966)
Reading at malicious_x = 0xffffffffffdfed6f... Unclear: 0xA2=’?’ score=982 (second best: 0xF5 score=979)
Reading at malicious_x = 0xffffffffffdfed70... Unclear: 0xA2=’?’ score=952 (second best: 0xF5 score=944)
Reading at malicious_x = 0xffffffffffdfed71... Unclear: 0xC4=’?’ score=973 (second best: 0x9B score=970)
Reading at malicious_x = 0xffffffffffdfed72... Unclear: 0xA5=’?’ score=982 (second best: 0xBE score=979)
Reading at malicious_x = 0xffffffffffdfed73... Unclear: 0x8C=’?’ score=992 (second best: 0x12 score=992)
Reading at malicious_x = 0xffffffffffdfed74... Unclear: 0x88=’?’ score=978 (second best: 0xC0 score=977)
Reading at malicious_x = 0xffffffffffdfed75... Unclear: 0xA2=’?’ score=961 (second best: 0x88 score=952)
Reading at malicious_x = 0xffffffffffdfed76... Unclear: 0xC8=’?’ score=988 (second best: 0xC9 score=987)
Reading at malicious_x = 0xffffffffffdfed77... Unclear: 0x9B=’?’ score=964 (second best: 0x4D score=955)
Reading at malicious_x = 0xffffffffffdfed78... Unclear: 0xFF=’?’ score=999 (second best: 0xFE score=999)
Reading at malicious_x = 0xffffffffffdfed79... Unclear: 0xC4=’?’ score=981 (second best: 0x6B score=979)
Reading at malicious_x = 0xffffffffffdfed7a... Unclear: 0x65=’e’ score=967 (second best: 0xBE score=965)
Reading at malicious_x = 0xffffffffffdfed7b... Unclear: 0xF4=’?’ score=990 (second best: 0x9C score=989)
Reading at malicious_x = 0xffffffffffdfed7c... Unclear: 0x76=’v’ score=980 (second best: 0x60 score=975)
Reading at malicious_x = 0xffffffffffdfed7d... Unclear: 0x88=’?’ score=982 (second best: 0xE1 score=980)
Reading at malicious_x = 0xffffffffffdfed7e... Unclear: 0x88=’?’ score=972 (second best: 0x3A score=971)
Reading at malicious_x = 0xffffffffffdfed7f... Unclear: 0xC4=’?’ score=963 (second best: 0x6B score=963)
Reading at malicious_x = 0xffffffffffdfed80... Unclear: 0xA2=’?’ score=951 (second best: 0xC4 score=950)
Reading at malicious_x = 0xffffffffffdfed81... Unclear: 0xF5=’?’ score=983 (second best: 0x88 score=983)
Reading at malicious_x = 0xffffffffffdfed82... Unclear: 0x88=’?’ score=971 (second best: 0x3A score=967)
Reading at malicious_x = 0xffffffffffdfed83... Unclear: 0xC4=’?’ score=971 (second best: 0xE5 score=970)
Reading at malicious_x = 0xffffffffffdfed84... Unclear: 0xA2=’?’ score=960 (second best: 0xC4 score=959)
Reading at malicious_x = 0xffffffffffdfed85... Unclear: 0x41=’A’ score=988 (second best: 0xFF score=986)
Reading at malicious_x = 0xffffffffffdfed86... Unclear: 0x2E=’.’ score=971 (second best: 0xEB score=970)
Reading at malicious_x = 0xffffffffffdfed87... Unclear: 0xA2=’?’ score=964 (second best: 0xC4 score=959)
Reading at malicious_x = 0xffffffffffdfed88... Unclear: 0xC4=’?’ score=957 (second best: 0xC9 score=956)
Reading at malicious_x = 0xffffffffffdfed89... Unclear: 0x8E=’?’ score=995 (second best: 0x8D score=995)
Reading at malicious_x = 0xffffffffffdfed8a... Unclear: 0x76=’v’ score=966 (second best: 0xC4 score=961)
Reading at malicious_x = 0xffffffffffdfed8b... Unclear: 0xF5=’?’ score=963 (second best: 0xA2 score=963)
Reading at malicious_x = 0xffffffffffdfed8c... Unclear: 0xBE=’?’ score=961 (second best: 0x1A score=954)
Reading at malicious_x = 0xffffffffffdfed8d... Unclear: 0x88=’?’ score=947 (second best: 0x3A score=946)
Reading at malicious_x = 0xffffffffffdfed8e... Unclear: 0x6B=’k’ score=984 (second best: 0xC4 score=982)
Reading at malicious_x = 0xffffffffffdfed8f... Unclear: 0xFE=’?’ score=999 (second best: 0xFD score=999)

кстати Касперскому парашют не интел подарила?

Сейчас есть патчи от спектра или это все-таки принципиально архитектурная лажа и не латается?

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

Это принципиальная архитектурная. Можно ли ее залатать - никто пока точно не сказал, хотя лично мне кажется, что можно.

Мне пришло в голову, что если spectre может читать память из user-space процессов, но всё-таки не может из ядра (ring 0), то очень костыльная заплата будет заключаться в переносе в ядро важных, чувствительных процессов, бывших до сих пор пользовательскими. Ну и видимо распихивание процессов по разным VM с полной (а не паравиртуализацией) тоже должно помочь. Правда такое распихивание - это не 30% будет потеря, тут IO раз в пять просядет.

Так в этом топике уже отписались люди со старыми моделям ЦП.

Тогда новость нужно править...

RedHat подготовил обновления

https://access.redhat.com/security/vulnerabilities/speculativeexecution

В CentOS 7 прилетело kernel-3.10.0-693.11.6

https://access.redhat.com/errata/RHSA-2018:0007

Тогда новость нужно править...

Сейчас.

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

Браузер в ядро будут переносить?

И что интересно, в первоисточниках везде пишут-modern processors...

https://lkml.org/lkml/2018/1/4/174 Гугл предлагает метод затыкания Spectre

Спасибо. Почему-то первоисточник удалили. Что-то не допилили в патчах?

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

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

Запустил на своем древнем атоме. Оно должно компилироваться на нем?

https://pastebin.com/0ujw0WxQ

Мне пришло в голову, что если spectre может читать память из user-space процессов

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

Что ты запустил? Выхлоп-то где?

а теперь про windows 10 x64

Только что было установлено обновления, после перезагрузки антивирус symantec endpoint protection сказал что приложение требует внимания. При открытии симантек показал что функция ливапдейт не доступна, горела серым. Через несколько минут сама по себе загорелась опять черным, типо стала доступной. Как бы это не оказалось в том числе фундаментальной функцией винды которая годами работала, а теперь из-за такого глобального изменения ядра некоторый софт начнет немножко не работать. Апдейт кстати 602 мегабайта, и только на это исправление как сказано.

Не везде. Еще раз - описываются 2 уязвимости, которые проявляются на процессорах разных временных отрезков.

Пожалуй. Уйду-ко я оффлайн, качать аниме буду только торрентами с трекерами без js...

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

Ну, если тебя устраивает низкая вероятность на PoC-коде - тебе волноваться не о чем.

Так оно не компилируется. Хз, что делать еще. Сделаю вывод что не работает.

Как оно не компилируется, если по выхлопу — скомпилировалось?

./sssss

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

Не хотелось бы нагнетать паники, но spectre пока что именно так фундаментально и выглядит.

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

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

Power'ы говорят тоже? Кто-то уже начал писать софтверный хак для иксбокса?

Ну подскажи что делать тогда.

Интересно, побьёт ли убытки от FDIV бага.

Проблема со FDIV была во времена, когда большая часть программ умела работать без сопроцессора. С другой стороны, тогда было легче сменить процессор — были конкуренты под тот же сокет. А сейчас бежать некуда.

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

Можно перевод с эзопова на русский?

линус в процах не понимает

Он какое-то время работал в Transmeta в команде разработчиков процессора над ядром, исполняющим микрокод.

Он сам тогда утверждал, что только админил сервера и с новыми процессорами дела не имел.

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

там же косвенная адресация эксплойтится. втягивается в кеш строка по адресу interesting_array[cookie], а отложенное исполнение позволяет проверку cookie обойти.

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

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

Запустить программу после компиляции?

$ ./sssss

Спасибо за замечание.

В первом случае (чтение данных внутри одного адресного пространства и кольца) не удивительно, что Intel не считает это уязвимостью. Ну потому что на уровне машинного кода инструкции не делают различий между указателями в недоверенных данных JS и данных самого VM. Но без второй уязвимости это не фатальная проблема - можно весь недоверенный код вынести в отдельный процесс с минимальным IPC. Это, скорее, плохой дизайн песочницы.

А вот второй случай (meltdown) - это очень плохо. Ядерный код (даже через eBPF) может читать всю память именно из-за этого. Ну, то есть, ты можешь спекулятивно исполнить код из ядра, потому что ядро замаплено. Но если оригинальная инструкция, которая начала спекуляцию, исполнялась в непривилегированном режиме, данные не должны (ну, как предполагалось писателями ОС) попадать в кэш без проверки прав доступа.

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

Не хотелось бы нагнетать паники, но spectre пока что именно так фундаментально и выглядит.

Пока что не сказано прямо, что чтение памяти других процессов возможно.

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

Поскольку микрокодом это похоже не лечится,

Я имел в виду относительно небольшие архитектурные доработки. Или даже флаг процессора «не вытеснять кэш при спекуляции».

ну да :D

https://pastebin.com/Nsd518r5

А вот второй случай (meltdown) - это очень плохо

Meltdown (насколько я понимаю) - подмножество Spectre, примененное к ядру, отображенному в пространство процесса + какая-то ошибка, связанная с недостаточным security check (ведь AMD, подверженный Spectre, не подвержен Meltdown).

Ну, то есть, ты можешь спекулятивно исполнить код из ядра, потому что ядро замаплено

Не поэтому, Эксплойт Spectre через eBPF сработает независимо от того, отображено ли ядро в юзерспейс.

Да уж.

описываются 2 уязвимости, которые проявляются на процессорах разных временных отрезков.

Ясно. Спасибо.

На этом выхлопе уязвимости в твоём Atom'е нету. Но сей эксплоит написан кем-то быстро на коленке. Поэтому утверждать что ты защищён от Spectre вряд ли будет правильным.

Проблема со FDIV была во времена, когда большая часть программ умела работать без сопроцессора.

Кроме того FDIV баг вылезал только на некоторых сочетаниях делимого и делителя, причём потеря точности была только в 4-м знаке после запятой. То есть, для большого количества софта, даже с вычислениями с плавающей точкой баг был не сильно критичен.

На этом выхлопе уязвимости в твоём Atom'е нету.

На старых Атомах (без OoO) его и не должно быть. На новых - таки должен.

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

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

Пока что не сказано прямо, что чтение памяти других процессов возможно.

А разве для чтения памяти своего процесса какие-то защиты вообще существовали, то есть, в чём тогда баг, что нашли способ это сделать через одно место? Хотя если против песочницы Javascript и прочих, то таки да, баг. Я не вникал в эту область, но мне казалось, что песочницы всё же отдельным процессом запускали, если нет, то кхм, вопрос тогда кто ещё тут дурак :)

Разумеется многое зависит от контекста, но в общем смысле meltdown - расплавление (разрушение в результате плавления). А расплавиться может много чего: кусок металла, ледяная статуя, кремовая розочка на торте и т. д.

Димка Бачило, помнится, 31 декабря 2017 года кудахтал об умирающих десктопах... Теперь вот померли все планшеты на необновленном Ведроиде. Бу-га-га-га!!!

Да, я уже прочитал все подробно.

Согласен.

Мнение вилсакома тоже надо узнать!

А разве для чтения памяти своего процесса какие-то защиты вообще существовали

«Защиты»? Всегда считалось, что код читает/пишет только те адреса, которые есть в коде (или вычисляются в коде). На этом основывались все внутрипроцессные песочницы. На данный момент эти песочницы бесполезны.

Это не говоря о том, что attack surface ядра ВНЕЗАПНО выросла.

Все планшеты на ARM64? В какой реальности? Обычные 32-бит армы то не подвержены.