Если кратко - из юзерлэнд под любой ОС на Intel и ARM64(?) можно получить доступ к системной памяти. Багфикс в процессе, но он убивает производительность. PoC Интел:
Here's everything I've been able to find so far:
-
The issue impacts all modern Intel CPUs. (Edit: It's been confirmed that the latest unaffected CPU is the original Pentium.) According to an AMD engineer, "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault." In short, AMD does not have the bug.
-
If successfully exploited, it could allow any program running on your computer (including a webpage with JavaScript) to access memory used by the operating system, giving it total control over your computer.
-
There is a patch in the works for both Windows and Linux that protects against this. However, the patch can cause a large impact on performance. It slows down any "syscalls" - function calls where the program talks directly to the operating system. This includes everything from opening files to communicating over the network; it is almost impossible to write a modern program without them.
-
The performance impact seen depends on the amount of syscalls the application makes. Raw number-crunching applications will see very little performance impact, whereas applications that have to talk to the OS a lot can see a large impact.
-
Raw numbers are hard to find due to the secretive nature of these patches, but here are some basic benchmark impacts we've seen so far:
-
Linux, on an i7 6700, calling the getpid syscall 100,000,000 times:
- Before the patch: ~3.8 seconds.
- After the patch: ~15 seconds.
-
PostgreSQL, a database application, i7-6820HQ, SELECT 1 benchmark:
- Before the patch: 420490.162391 transactions per second
- After the patch: 350746.065039 transactions per second
-
Итак, благодаря бдительному и неленивому камраду Нехороший имеется расширенное толкование и пояснение:
Разработчики из Google Project Zero опубликовали детали уязвимостей, которые затрагивают не только процессоры Intel и ARM64, но и AMD тоже (есть сообщения, что только при включении BPF JIT в ядре, что по умолчанию выключено). Названия им дали: Meltdown и Spectre (расплавление ядерного реактора и призрак).
Meltdown позволяет приложению читать любую память компьютера, включая память ядра и других пользователей. Этой атаке подвержены процессоры Intel (по неподтвержденным данным все модели с 1995 года, кроме Itanium и Atom) и ARM64.
Spectre создаёт брешь в изоляции различных приложений и позволяет атакующему обманным способом получить данные чужого приложения. Этой атаке подвержены процессоры Intel, AMD, ARM64, Power8 и 9.
Эксплоит, эксплуатирующий Meltdown позволяет читать память ядра со скоростью 2000 байт в секунду на процессоре Intel Xeon архитектуры Haswell.
Уязвимостям назначены следующие CVE: CVE-2017-5753, CVE-2017-5715 и CVE-2017-5754.
Напомню, что пользователи ежедневно запускают чужой код на своих компьютерах, посещая веб сайты с JavaScript (>99%), поэтому применение патча (здесь и здесь) обязательно, если вы дорожите своими данными. Есть PoC (п.4.3) , демонстрирующий атаку с этой уязвимостью через JavaScript.
Разработчики ARM приводят подробности атаки для ARM, заявляют о том, что уязвимы лишь некоторые процессоры ARM, дают их список и меры по повышению безопасности
эта фича заложена в конструкцию ВСЕХ без исключения вычислительных устройств, произведенных
последние 10 лет в тщетных попытках инженеров обойти НЕИЗБЕЖНЫЙ тепловой тупик, с которым
продвинутые люди в теме были хорошо знакомы уже лет пятнадцать и каждое упоминание которого
неизбежно вызывало оскорбительные эпитеты в адрес автора со стороны подлецов и подонков.
Теперь выход один - или радикально УХУДШИТЬ производительность ВСЕХ процессоров, отбросив состояние
дел на пятнадцать лет назад, где оно по всем фундаментальным основам и должно было пребывать уже НАВЕЧНО,
либо смириться с тем что ЛЮБЫЕ вычислительные устройства будут напрочь ОТКРЫТЫ ВСЕМ кому не лень их взломать.
Никаких “облаков”, никаких “амазонов”, никаких смартфонов - все без исключения надо выбросить сегодня
и сейчас, если там есть нечто стоящее, выжидая несколько лет пока интел не наладит снова выпуск более устойчивых процессоров образца 2004-го года, куда мы все неизбежно откатимся.
https://golos-dobra.livejournal.com/1057823.html
Комментарии
Это не баг, это фича.
ну да, типа недавней про IME. многовато у Интела фич в последнее время на тему очень клёвых бэкдоров :-)
а не загнул ли автор насчет опасности выполнения джаваскрипта в браузере?
Не загнул: https://www.react-etc.net/entry/exploiting-speculative-execution-meltdow...
Правда разработчики браузеров вроде могут это побороть. Скорее всего с таким же падением производительности.
да, есть описание того, как это теоретически можно сделать при помощи джаваскрипта с кучей оговорок и применением других различных технологий. Может я неправ, но есть подозрение, что для успеха операции должно будет сойтись слишком много звезд на небе, и такой эксплойт придется разрабатывать индивидуально под каждого конкретного клиента, и все это ради того, чтоб иметь возможность заглянуть на секундочку через замочную скважину в кэш его проца, в котором может быть, если опять очень очень повезет, в этот самый момент окажется номер его кредитки, про который еще надо будет как-то понять, что это он и есть. Похоже среднестатистическому пользователю афтешока следует больше переживать, что ему зашлют дрона с камерой, который через окно снимет, как он вводит свой пароль с клавиатуры.
Грейтэгейн! Придется новый комп покупать, блин...!
Не новый, а старый ;-)
Кроме шуток. Где-то видел заметку о том, что айфоны тормозят старые версии, типа чтобы заряд батареи дольше держался (на самом деле, чтобы лохи поскорее новые телефоны покупали), а Интел рассказывает о жуткой дырке в процессоре в тот момент, когда нужно сделать Америку грейтэгейн, а именно продать кучу барахла за большие деньги - новые процессоры.
Я понимаю, что звучит как ТЗ, но что если суть именно в том, чтобы все срочно накатили какой-то там патч, который чего-то там добавит, но по большому счету никто не станет смотреть что?
Микрософт и так регулярно патчи выдаёт. В Linux kernel патч уже все посмотрели и даже внесли изменения (убрали тормоза на AMD и Intel Atom)
Самое неприятное, что этот жирный песец внимательно смотрит в сторону виртуализации :-(
Да уж.
Если ВМы не изолированы друг от друга на аппаратном уровне, то все облака накрываются медным тазом.
"Будет ласковый дождь..."
я уже добавил в авторский. последствия реально чудовищные.
К херам-то они может и не пойдут, запатчат же, но просад производительности виртуальных сред будет адский.
почему я думаю чо будет грустнее? ну как надо было реализовывать VT extesions чтобы их вот так всё обходило? текущую-то проблему попатчат, а что делать с концепцией реализации виртуализации на интелах?
Юные геймеры уже в ужасе от такой перспективы. Деть сказал - "Не буду свой линух обновлять!!!
" Через несколько часов - "А придётся.
"
Учитывая что этому багу уже 20+ лет, последствия все какие могли быть уже случились.
ну тоже мнение. тогда надо ставить вопрос о выявлении и зачистке последствий, раз уж всплыло. а сколько ещё всплывёт?
Apple: Мы сокращаем производительность яйфонов, как только приходит конец их батареям и не сообщаем об этом вам.
Intel: Мы сокращаем производительность каждого процессора в мире на 30% из-за старой дырки в нашей архитектуре процессоров.
Итоги:
Разве полмиллиона доморощенных хомячков, которым это сейчас слили, уже наклепали из конструкторов эксплойтов на базе этих уязвимостей?
от публикации критичной дыры до эксплойта обычно 8-10 часов..... развертывание в интернете системы эксплуатирующей "дыру" 3-5 дней.... и это С НУЛЯ, если уже есть схемы "вывода" и тп то все в разы быстрее.......
ДУМАЙТЕ.....
Фигня, аналог проблемы 2000.
Для эксплуатации уязвимости требуется совершенно конкретное поведение - экстремально высокий темп ошибок по защите памяти, столь же высокий темп переключения контекстов - что и приводит, кстати к очень скромному темпу дампирования памяти. Данное поведение будет, несомненно, мгновенно выявляться антивирусами, и проблема стухнет.
Ну, если не считать массовую закупку нового железа и принудительные тормоза для всех операционок, заботливо вставленное в них вендорами
Выше написал, что вся эта шумиха (а сегодня такой прием не новость) просто для отвлечения и накатки определенного кода.
для хомячков - да
главная жопа это "виртуализация" и Публичные облака
значит, будут платить за толковый файрвол, либо гонять в публичном облаке код с ценностью, равной нулю. А всякие вордпресы как ломали так и будут ломать
Очевидно, что раз запускаешь свою подсистему на неизвестно чьём железе в компании с неизвестно кем, значит не стоит надеться на конфиденциальность своих данных. Ситуация равна той, что тормознули виртуалку, скопировали из неё всё, что надо, и дальше запустили. И совершенно нет разницы, было ли это ЦРУ, СБУ, вендор или вася с соседней улицы.
Если бы. Псевдокод выглядит так:
Код readbyte(address) никогда не выполняется (так как x=0), поэтому ошибки памяти нет, но из-за спекулятивного выполнения, в тот момент, когда readbyte(address)==n всё равно должен довычисляться atan. А значит в этот момент время выполнения станет чуть больше.
P.S. На самом деле if (readbyte(address)==n) делать нельзя, так как он даст ещё одну ветку конвейера, там нужно использовать функцию, которая для разных значений выполняется разное время. Но суть того, что отловить такое поведение через контроль того, что выполнилось, невозможно.
сдаётся мне, что железу безразлично, было ли чтение в "опережающем" режиме, или в обычном потоке исполнения. Я бы поставил на срабатывание исключения по защите памяти от чтения.
Не безразлично. Было бы странно получать ошибку чтения памяти на код x = 0; if(x) { /* здесь доступ к памяти */ }.
Поэтому проверка прав и вызов исключения происходят только если выполнение действительно пошло по этой ветки (предсказание было верно). Ошибка в том, что предсказанная ветка выполняется без проверки прав. Права проверяются только если исполнение действительно пошло по этому пути. Типа оптимизация.
нормальные компиляторы такой код выкусывают при оптимизации и у правильных пацанов всё оки. А гики, задачей которых является поиск недокументированных фич, могут перетоптаться и с исключением. Впрочем, это лишь моё предположение
кроме того, если вы прочитали описание проблемы, то люди ловят не реальное чтение, а заполнение кэша и позже пытаются выяснить, что именно закэшировалось. Загрубление таймера решит данный вопрос. Частый замер времени позволит выявить сигнатуру атаки.
Проблема есть, но не ужосужос
Код может быть и такой: int x = factorial(5) - 120; if(x) { ... };
С учётом того, что 99% кода с исключением будет выглядеть как if(p) { x = *p } (если указатель заполнен, то разыменоваваем) или даже if(o.alive) { x = *o.ref } (здесь как раз будет ошибка доступа, а не разыменование пустого указателя, если условие игнорировать), то я очень сомневаюсь, что это хорошая идея.
повторюсь, у компилятора есть калькулятор :) и константные выражения вычисляются загодя, по ним же делается оптимизация, в том числе исключение неисполнимого кода. На хабре была классная статья на эту тему, не могу найти
Поэтому в нормальном коде такой кусок не сработает.
говорю же, вы копаете не туда. Утечка идёт по побочному каналу. Железо не даёт прочитать данные напрямую, это исключение. Изучается быстродействие - что именно попало в кэш в качестве prefetch. Проблему, ИМХО, можно решить загрублением таймера, атаку выявить его интенсивным использованием
Откуда компилятор знает, что функция factorial из внешней библиотеки возвращает константное выражение? И не форматирует диск, например. Ведь если форматирует, то это должно происходить не при компиляции программы, а при выполнении.
А по сути смотри второй абзац про указатели. Такой код встречается массово и компилятор его выкинуть не может.
В JS так сделано. "JavaScript does not provide access to the rdtscp instruction, and Chrome intentionally degrades the accuracy of its high-resolution timer to dissuade timing attacks using performance.now() [1]. However, the Web Workers feature of HTML5 makes it simple to create a separate thread that repeatedly decrements a value in a shared memory location [18, 32]. This approach yielded a high-resolution timer that provided sufficient resolution." © https://spectreattack.com/spectre.pdf
То есть достаточно сделать второй поток с циклом и считать такты.
Да, конечно, вы правы.
собственно, с этим уже борются.
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-cla...
Для JS в браузере это подойдёт. Для виртуалок и произвольного кода это фактически запрет на многопоточные приложения.
Большое спасибо за код, так намного понятнее в чем проблема. Только подправьте плз, вместо x=0 на тот же факториал, ибо реально даже gcc с -O0 просто выкинет эту проверку нафиг. Добиться желаемого поведения на C++ компиляторах та ещё задача. И вот это бы тоже развернуть:
А то не особенно понятно, то ли это должно выполниться много раз, то ли просто непонятная инструкция непонятного псевдокода.
Я даже не знал до сегодня о такой фиче процессоров как спекулятивное выполнение, впрочем на том языке в котором я работаю такого наверное и не добиться(
суть вот в чём
Есть область памяти, недоступная для user. Мы хотим прочитать один байт по некоторому адресу А.
Для этого берётся массив B[ 256 х длину строки кэша], нам доступный, и пытаемся адресоваться в нём байтом из недоступной нам области памяти. Однако, код, который это делает, помещаем в недостижимый по потоку исполнения фрагмент.
Процессор, обнаружив ожидаемую попытку косвенной адресации, подтягивает в кэш строку B[@A х длину строки кэша] из нашего буфера, соответствующую содержимому байта из недоступной нам памяти. Однако, поскольку фрагмент реально не исполняется в нашем потоке, то мы "как бы" и не читали этот байт, потому исключения по защите памяти может не случиться. Результатом будет кэширование строки нашего массива, соответствующей содержимому байту @A. Поэтому речь идёт о строке, равной размеру строки кэша. Мы не можем подтянуть один байт из массива В.
После чего мы читаем наш массив, и смотрим время доступа. Если мы читаем строку, которая уже в кэше, это происходит быстрее, чем строка, которой в кэше нет. Таким образом, можно сделать предположение о содержимом байта по недоступному адресу. Отсюда необходимость выполнять чтение многократно, что бы дельта по времени стала заметной. Так же отсюда необходимость выполнять процедуру многократно, что бы набрать значимую статистику. В итоге, низкая скорость доступа до служебных данных и вероятностный результат.
И ещё надо молиться за то, что бы это добро отрпботало в одном кванте времени и ОС не перекинула в другое ядро.
Теже кеды очень ловко перекидывают по ядрам, что бы они грелись боле-менее равномерно.
Проблема достаточно просто решается, если юзать vmware со всеми заплатками, в том числе и ядерными, типа - сунулся не к себе без разрешения - процесс убивается - потом юзверю объяснить, что он хватнул каку и его машина будет лежать до тех пор, покуда он не переустановит систему, иначе оная будет ребутаться до морковкиного заговения. Под Windows - такой вариант не работает, только если патчить жестко.
Так для использования дыры не надо никуда соваться без разрешения. Достаточно в одной половине разветвления нарисовать доступ к несвоей памяти, а выполнять другую половину. Интеловский доставальщик из памяти занесёт в кэш содержимое обеих веток - не проверяя: есть ли разрешение на доступ к ним.
Рекомендую проверить, достаточно повесить немаскируемое прерывание в ядро с контролем доступа к своей памяти и все попытки лезть куда не надо - можно пресекать так, как считаете нужным. Проверял. А вся беда в том, что программисты ПРИВЫКЛИ к железной защите и пользуют стандартные библиотеки, но не заботятся об основах...))))
if таблица__не_инициализирована :
запросить заполнение таблицы
сделать переход по адресу из таблицы
Интеловский оптимизатор выполняет обе ветки ветвления. Понятно, что если таблица не инициализирована, переход по адресу из таблицы будет в куда_не_надо,
Защита, которая отрубает программу из-за того, что переход внутри одной из веток стоит не туда, такую программу убьёт. А программа - нормальная.
Не факт, поскольку ветвление требует в ОС создания блока описания потока и регистрации в планировщике. В этот момент пользовательский процесс будет приостанавлен и с вероятностью на ноль целых и ноль десятых менее единицы будет вытеснен. За то время, пока он вернется на ядро, выполнится куча кода, как самого ядра, та и полусотни других процессов и потоков, которые все кеши покурочат под себя.
Вы ведь про ветвление, которое создание новой ветви (thread), потока выполнения команд? Да, согласен. Но я под ветвлением подразумевал ветвление внутри одного потока выполнения, код, который возникает в результате компиляции условного оператора "if".
Об этом не подумал. Тогда ждем возврат итаниума и взлет эльбруса. Во втором планирование потоков статическое на стадии кодогенерации, возможно в первом аналогично.
Ха! А для таких целей и существуют серые сети, которые не побомбишь...)))))))))))
Жесть.
Недаром фон Нейман и Doomsday machine придумал.
Не нагнетайте - это все для удобства и безопасности пользователя! )))
Ну так и Машина Судного дня - тоже :)
Похоже пора переходить на Qubes OS
Страницы