- 1
Давайте обсудим meltdown и spectre.-
Куча / Говнокод #23642
0
Объясните мне кто-нибудь, в чем принципиальное отличие spectre от meltdown? И как оно позволяет читать память других процессов? Все что я пока понял - это чтение памяти ядра, которое уже все прикрыли, и проблемы с жс в браузере.
Запостил:
FrauSchweinhund,
06 Января 2018
Follow us!
> И как оно позволяет читать память других процессов?
При speculative execution процессор имеет право положить хуй на if и начать выполнять любую его ветвь до того, как он проверит, что реально попало в if - если считает это нужным. Все, что грузится в этой ветви, проходит через кэш процессора, что позволяет как минимум косвенным образом выяснить, что там внутри валялось.
Краткий пересказ:
- Есть спекулятивное исполнение, которое выполняет ветку условного перехода, которая по мнению процессора должна выполниться (предсказание переходов) до того, как выполнится собственно само сравнение. При этом на уязвимых процах не задействуется MMU, который должен давать по рукам за попытку обращения к чужой памяти (та самая ошибка "программа обратилась"), по крайней мере сразу. Т.е. сначала выполняется операция и потом только MMU начинает гавкать.
АМД неуязвимы потому что у них MMU проверяет права доступа сразу при исполнении, по заявлению их работника.
Результаты хранятся скрыто, к ним нельзя обратиться через проц.
- На всех процах есть косвенная адресация (прочти мне ячейку памяти по адресу, лежащему в регистре). Еще там есть кэш, разница по скорости обращения к памяти и кэшу огромная - к памяти сотню циклов (хз сколько на самом деле), к кэшу первого уровня - 1 цикл проца.
- Результаты спекулятивного исполнения влияют на кэш.
Сценарий атаки такой:
Создаются условия для того, чтобы проц посчитал условный переход выполняющимся.
Процессор в спекулятивном режиме читает значение по адресу 15000. Пусть там будет лежать, например, 98.
Процессор читает значение, лежащее по адресу 98.
От MMU приходит ответ о невалидности адреса 15000.
Процессор сбрасывает конвейер и вместо значения, лежащего по адресу 98, выдаёт нам ошибку.
Наше приложение начинает читать адреса от 0 и выше в собственном адресном пространстве (имеет полное право), замеряя время, требующееся на чтение каждого адреса, и читая их не по порядку, чтобы не натренировать тот же спекулятивный доступ
На адресе 98 время доступа вдруг оказывается в несколько раз ниже, чем на других адресах
> вся физическая память компьютера
Видимо вот так читать память других процессов.
Ещё PAE есть, с помощью которого можно хоть черта лысого адресовать, но это экзотика.
Но я могу ошибаться.
> https://sohabr.net/gt/post/297029/
>>Нормальная
>>habr
Тебе самому не стыдно-то?
По ссылкам не ходил, но сайтец наверняка кацапский, хоть и .net.
Meltdown:
Выкидываем arr из кэша нахуй, занимаем процессор обсчётом муторной хуйни, и дальшн пишем arr[x]. Часть процессора, которой нечем занятся, делает out of order execution и загружает этот arr[x] в кэш. Выполнение доходит до строчки arr[x], процессор обнаруживает, что Х недоступна, и кидает исключение. Программа его обрабытывае и начинает тыкать arr, проверяя, какой элемент быстрее загрузится, а значит, лежит в кэше. Если 42 элемент, значит Х == 42.
Патч: Смывать кэш нахуй каждый раз когда происходит нелегальный доступ.
Spectre:
Тренируем очко branch predictor, что какое-то условие всегда истинно. Смываем кэш arr. Затем ВНЕЗАПНО делаем его ложным, и пихаем в тело arr[x]. arr[x] загружается в кэш, выполнение реально доходит до условия, ОЖТЫЖЁБАНЫЙНАХУЙПРЕДИКТОРОШИБСЯ, выполнение идёт дальше. Так как реально попытки доступа к запрещённой памяти не было, исключения нет, и никто не в курсе, что произошло. Дальше находим Х из номера элементы arr находящегося в кэше.
Как читать память других процессов не ебу ещё, можно почитать здесь: https://spectreattack.com/spectre.pdf
Нет. Патч - не держать память ядра в текущем адресном пространстве.
Да. Meltdown эксплуатирует игнорирование процессором уровней доступа к памяти, но не позволяет читать память, находящуюся за пределами выделенного приложению виртуального блока.
Для всех распространённых ОС уже вышли или готовятся выйти патчи, переносящие область памяти ядра в другую облась, т.е. обеспечивающие защиту не только выставлением привилегий, но и контролем доступа по адресам — второе Meltdown обойти не может.
Проблема в том, что при такой архитектуре системные вызовы (syscalls) становятся крайне накладными — они замедляются в несколько раз. Соответственно, реальные приложения также теряют в производительности, в зависимости от доли системных вызовов в конкретном приложении падение может составить от 1-2 до нескольких десятков процентов. Например, на PostgreSQL продемонстрировано падение более 20 %, в то время как в игрушках разницы практически нет.
Судя по всему, доступ к памяти идёт от имени процесса-жертвы. Т.е. вместо arr[x] там jz (адрес подобной конструкции в коде жертвы)
ASLR?
Надо случайно обфусцировать бинарь при загрузке, как это делали всякие защиты от крякеров. Только воспроизводить баги и смотреть корки уже не получится.
https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html
---
TL:DR
Глобальная ошибка, присутствующая примерно во всех существующих процессорах. Была бы полной жопой, если бы не высокая сложность практической реализации, из-за которой хакеры на неё забьют.
AMD, похоже, наполовину безопаснее прочих, хотя и непонятно, почему.
TL:DR — разница с Meltdown
Meltdown использует ошибку в процессорах Intel и ARM, из-за которой при спекулятивном выполнении инструкций процессор игнорирует права доступа к памяти.
Spectre использует особенность работы алгоритмов предсказания ветвлений и переходов в современных процессорах, из-за которой один процесс может влиять на вероятность спекулятивного исполнения инструкций в другом процессе.
амд никогда так аггресивно как интел не параллелил исполнение. поэтому они слегка медленее и работают.
с другой стороны, параллелизация + игнорирование ошибок - я теперь понимаю как интел производительность подымал в последние годы. потому что прирост герцами и оптимизациями было трудно объяснить. а с таким out-of-order которому все до жопы... то тогда да, понятно.
Да потому что у них ничтожная доля рынка и этот АМД никому нахер не впёрся!
На самом деле у зелёных тоже багов полно. Просто после десяти лет выпуска малоконкуретных процессоров трудно вызвать былой интерес.
Помнится эпичная бага у АМД, с кешем TLB. Просто интел/арм повсеместен, потому исследуют его сильнее.
Как и те же винды. В мире линукс софта дыр и переполнений не меньше, т.к. всё написано на той же сишке. Но у винды доля десктопного рынка на порядок больше, а квалификация среднего юзера ниже.
Microsoft приостановил распространение патча от Meltdown и Spectre — он вешает компьютеры на процессорах AMD
Компьютерам под Windows с некоторыми процессорами AMD не удаётся загрузиться после установки патча от уязвимости Meltdown/Spectre.
Представленное компанией Microsoft экстренное накопительное обновление безопасности под Windows для устранения недавно выявленных уязвимостей Meltdown и Spectre приводит к возникновению ряда новых проблем и непредсказуемых последствий.
Жалобы от пользователей систем на базе процессоров AMD на сбои и возникновение ряда новых проблем начали появляться на форуме пользователей Microsoft сразу же после выпуска нового защитного патча.
Согласно этим сообщениям, проблемы возникают у владельцев систем на процессорах Athlon, получивших кумулятивное обновление безопасности KB4056892 и инсталлировавших его на системах с установленным обновлением Windows 10 Fall Creators Update.
Security
It gets worse: Microsoft’s Spectre-fixer wrecks some AMD PCs
KB4056892 is not your friend if you run an Athlon
Users report Athlon-powered machines in perfect working order before the patch just don’t work after it. The patch doesn’t create a recovery point, so rollback is little use and the machines emerge from a patch in a state from which rollback is sometimes not accessible. Some say that even re-installing Windows 10 doesn’t help matters. Others have been able to do so, only to have their machines quickly download and install the problematic patch all over again …
Охуенно, чо. Чинили одно — сломали другое.
Отключить интернет эти гении не догадались...
Symptom: Microsoft has reports of some customers with AMD devices getting into an unbootable state after installing this KB. To prevent this issue, Microsoft will temporarily pause Windows OS updates to devices with impacted AMD processors at this time.
Workaround: Microsoft is working with AMD to resolve this issue and resume Windows OS security updates to the affected AMD devices via Windows Update and WSUS as soon as possible. If you have experienced an unbootable state or for more information see KB4073707. For AMD specific information please contact AMD.
Эта история становится всё лучше и лучше.
Нет, ну вот-как-то, а?
Может они под видом т.н. "патча" еще бекдоров добавили?
Это зелень? Тут баг, общий для нескольких типов процев, но не работающий на AMD.
А что там обсуждать? Нам всем пиздец.
народ на интернете поговаривает о судебном процессе против интела, т.к. они: знали о проблеме уже пол года; до последнего момента отрицали что это баг; тыркали пальцами в конкурентов в то время как сами не останавливались продавать дефективные процы; на текущий момент даже и следов что они что-то фиксят микрокодом пока нету.
с другой стороны, факт что фиксится (и фиксится другими, а не интелом), не оправдывает того что интел на проблему забил и продолжал продажи.
> Ты думаешь в железе ее пофиксить хуй да нихуя?
для этого уже 20+ лет (после fdiv бага) существует "microcode" - механизм для фиксов багов проца, которым (интел хвастался) они буквально все могут пофиксить.
но так как надо сбрасывать кэши, я думаю интел это спихнул на ОСы, потому что это плохо для производительности, и они скорее из-за плохого маркетинга это будут пытаться избегать делать. если процы тормозят из-за интела - то это как бы плохо для интела. если процы тормозят из-за ОСи - то у интела есть отмазка.
> у интела есть отмазка
Но патчи в осях же только на интелах включены и тормозят...
Давай пруфы
> но так как надо сбрасывать кэши
Когда?
> если процы тормозят из-за ОСи - то у интела есть отмазка.
Я думаю они даже с патчами будут ебать amd в хвост и гриву. Время реальной конкурренции ушло.
> Когда?
часть того что делают софт фиксы, это сброс кэша когда меняетя контекст исполнения/секурити контекст (интеррапт, системный вызов или эксепшн). это все реализуемо в самом проце.
и это уже фикс ... то ли для первого, то ли второго экплоита.
Ну ладно, посмотрим. Кстати, а посадить троян/бекдор в микрокод можно?
Интелу - запросто. Остальным - х.з., всё-таки там цифровая подпись какая-то есть.
У проца флешки нету, микрокод заливается BIOS'ом на каждом старте. Т.е. в теории можно даунгрейднуть/пропатчить прошивку (но прошивки сейчас не особо любят даунгрейдиться).
Как вариант. Операционки, по идее, тоже могут микрокод лить. Лишь бы версия заливаемого микрокода была больше, чем та которая сейчас в проце.
> защита от даунгрейда биоса
Тупо отказывается принимать старую прошивку. Программатором пока ещё можно что угодно залить...
З.Ы. А вот на некотрых приставках при апдейте "выжигали" фьюзы, чтобы старая прошивка больше никогда не могла запуститься...
Даже легче чем кажется. Всякие убунты просто грузят его на старте.
$ apt policy intel-microcode
Проверять:
$ dmesg | grep microcode
а вектор интересный. микрокоды заливаются раз, и никаких проверок после на них не делается.
микрокодом добавляешь баг, а потом в юзверспэйсе его "экплоитишь" что бы делать все что хочешь в любой момент времени - и не оставляя следов.
Ну вот сейчас исследование читаю - там 2048-битная RSA подпись.
З.Ы. Ну вектор не такой уж интересный - залитый микрокод после резета пропадёт, а патчить BIOS - следы останутся (проще тогда туда код въебать, хоть RSA ломать не придётся).
Для AMD K8 таки смогли (там апдейты микрокода были с простой чексуммой и не зашифрованные): https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf
З.Ы. Пиздец у чуваков ресурсы были:
In order to remove layers, we used a combined approach of Chemical Mechanical Polishing and plasma etching. During inspection of the seventh layer, we encountered the expected ROM array structure. We acquired images of individual layers using a Scanning Electron Microscope since optical microscopy reaches diffraction limits at this structure size.
А разве компы найденные на свалке меняют? Возможно ты не помнишь, т.к. болтался у папки в яйцах, но в 90х меняли пеньки, когда FDIV ёбнул.
И чо, в снг кому-то что-то поменяли?
ответственность падает на Samsung/Apple/STM/TI/etc которые арм дезайнами пользуются, но их все равно кастомизируют.
и в отличии от интела, на армах нет микрокода, которым это можно пофиксить. для арма в любом случае нужен софтварный фикс в ОС.
А кто тебе сказал что это можно пофиксить микрокодом?
Оооо. Микрокод — это отдельная епархия.
Непонятно что вообще страшнее: аппаратные баги или намеренные бэкдоры в микрокоде.
Если правда вскроется, то не отмоешься же.
Гойсподи, да у них постоянно такое вскрывается.
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr
А тот эпик с RDRAND, аппаратным генератором рандома, когда пало подозрение на контроль NSA что писали массовую петицию выкинуть нахуй кернела.
https://crypto.stackexchange.com/questions/10283/could-rdrand-intel-compromise-entropy
Двойной фейл
>Intel CPU since 2010.
Вот что интересно.
Не зря её штеуд отключал, ох не зря.
https://business.f-secure.com/intel-amt-security-issue
Блин, я думал там что-то интересное... А на деле - тупо доступ к настройкам большого брата AMT по-умолчанию оставили открытым.
Про спектр пока не читал, было не до того.
В адресном пространстве процесса есть ядро, но из юзерспейс кода (в сегменте с dpl=3) читать его нельзя:
получишь fault потому что там у страниц запрещен доступ из userspace.
У CPU е разные модули (ALU, AGU итд) и всех их надо загрузить: потому проц выполняет микрокоманды спекулятивно:
if (*foo) {bar=42 + 1}. Пока один вычиляет foo(представим что branch prediction не работает), другой считает 42+1.
Если *foo==FALSE, то результат откидывается.
Почитать подробнее можно в мануале про pipelines и в вики про hazards и алгоритм Tomasulo.
Когда почитаешь и поймешь как reservation stations обменваются по CBS и что такое register rename
-- возвращайся и читай дальше.
Код "MOV AL, [KernelSpaceAddr]" вызовет fault, но к этому моменту он уже может быть выполнен, потому
что проверка выполнялась параллельно с кодом. Физически данные будут во "внутреннем" регистре (см register rename)
и никогда не станут доступы следующей инструкции потому что всё это проц нахуй выкинет следующим шагом (потому что fault).
То-есть у нас такой "код в другом мире" считал память, но передать ее дальше не может.
Есть side channel аттака на кеш Flush+Reload (советую почитать) на основее нее сделано то, что происходит дальше.
Если флашнуть кеш (cflush) а потом считать данные из памяти то загрузка займет долгое время, а если из прочитать то
кеш будет заполнен и времени нужно будет меньше.
ПРОДОЛЖЕНИЕ НИЖЕ
Process1: cflushшит доступную ему память и порождает Process2.
Process2: читает байт из памяти ядра и использует его для индексации в массиве в доступной ему памяти
foo=*kern_space; bar = *(addr_of_somemem += (4096 * foo)) и тут его настигает fault.
Process2 может поставить хендлер или сдохнуть или использовать транзационную память, не важно что с ним дальше.
Важно что если он считал 0 то addr_of_somemem теперь в кеше
А если 1 то addr_of_somemem + 4К теперь в кеше.
Теперь Process1 просто читает addr_of_somemem и замеряет время.
Малое время addr_of_somemem -- считали 0
большое время -- считали 1.
Лечится KAISER: убираем из адр. пространства процесса все ядро кроме нужного (обработчики прерыв итд)
Вот тут все на пальцах: https://meltdownattack.com/meltdown.pdf