Здравствуйте, wildwind, Вы писали:
C>>Spectre является более общей уязвимостью и полной защиты от неё пока что нет. W>Пока что для успешной атаки требуется внедрение своего кода в целевой процесс/ядро.
Тут уже нашли другие последовательности, которые позволяют эксплуатировать Spectre. И видимо, что такое будет продолжаться ещё долго.
Здравствуйте, vsb, Вы писали:
vsb>Spectre вообще никак не обходится, насколько я понимаю, с ним придётся жить ближайшие лет 10. Так что тут обсуждать особо нечего. Но в целом он полагается на точные таймеры, и браузеры возможность получения точной информации о времени в жаваскрипте урезают в следующих версиях.
Им пришлось отключить SharedByteArray — единственный способ организовать многопоточность с разделяемыми данными в JS.
Здравствуйте, Pzz, Вы писали:
C>>Meltdown специфичен для Intel и позволяет из userspace-процесса прочитать всю физическую память, включая ядро и гипервизор. Защита только через KAISER для Линукса ( https://lwn.net/Articles/741878/ ) или аналогичное изменение для NT. AMD не подвержен конкретно этой уязвимости. Pzz>А объясни, пожалуйста, мине, тупому, каким образом возможность разнюхать kernel pages layout из user space превращается в возможность прочитать содержимое ядерной памяти?
Можно организовать пробы, которые утекают по одному биту содержимого. А одного бита со сдвигом уже достаточно, чтобы получить всё остальное. В результате, память читается со скоростью 500 килобайт в секунду.
Из моего понимания:
char *data = 0xFFFFa123123; // В ядреif ((*data) & 0x01 != 0) { // Упадёт здесьchar *probe1 = 0x123123123; // В нашем адресном пространстве
*probe1 = 123;
} else {
char *probe1 = 0x234123412; // В нашем адресном пространстве
*probe1 = 234;
}
Этот код, естественно, падает на SIGSEGV. Но проблема в том, что CPU успевает таки спекулятивно исполнить одну из проб. И затем с помощью тестирования кэша можно обнаружить какая проба сработала.
Здравствуйте, Cyberax, Вы писали:
vsb>>Spectre вообще никак не обходится, насколько я понимаю, с ним придётся жить ближайшие лет 10. Так что тут обсуждать особо нечего. Но в целом он полагается на точные таймеры, и браузеры возможность получения точной информации о времени в жаваскрипте урезают в следующих версиях. C>Им пришлось отключить SharedByteArray — единственный способ организовать многопоточность с разделяемыми данными в JS.
Ну неприятно, конечно, но суть в том, что проблема на данный момент решена. А потом придумают что-нибудь. Я так понимаю, Spectre позволяет читать только из своего процесса, то бишь достаточно запускать JavaScript в отдельном процессе.
Здравствуйте, vsb, Вы писали:
C>>Им пришлось отключить SharedByteArray — единственный способ организовать многопоточность с разделяемыми данными в JS. vsb>Ну неприятно, конечно, но суть в том, что проблема на данный момент решена. А потом придумают что-нибудь. Я так понимаю, Spectre позволяет читать только из своего процесса, то бишь достаточно запускать JavaScript в отдельном процессе.
Spectre работает и в ядре, но требует определённых последовательностей кода (например, стандартной проверки границ). Сейчас пишут плугин для gcc, который будет избегать опасные последовательности, но уже ясно, что пытливые умы хакеров будут находить новые методы обхода.
Здравствуйте, Cyberax, Вы писали:
C>Можно организовать пробы, которые утекают по одному биту содержимого. А одного бита со сдвигом уже достаточно, чтобы получить всё остальное. В результате, память читается со скоростью 500 килобайт в секунду.
Спасибо.
Охренеть можно. А как из сделать то же самое из JS?
C>Этот код, естественно, падает на SIGSEGV. Но проблема в том, что CPU успевает таки спекулятивно исполнить одну из проб. И затем с помощью тестирования кэша можно обнаружить какая проба сработала.
Здравствуйте, Grizzli, Вы писали:
AD>>В зависимости от ОС и метода от 122 до ~500 КБ/с.
G>мне казалось, содержимое кеша меняется в секунду тысячи раз как минимум?
Это неважно, пока есть статистически надёжная проверка, попала ли какая-то строка в свежую загрузку (а, учитывая тотальный LRU в процессорах, раз она недавно трогалась, она не скоро будет вымыта из кэша). Что там при этом происходит с хвостом содержимого — пофиг.
И, пока кэш эффективно выполняет свою роль, тут алгоритм не так важен (годится даже случайное замещение, как в ранних AMD).
Здравствуйте, netch80, Вы писали:
N>Это неважно, пока есть статистически надёжная проверка, попала ли какая-то строка в свежую загрузку (а, учитывая тотальный LRU в процессорах, раз она недавно трогалась, она не скоро будет вымыта из кэша). Что там при этом происходит с хвостом содержимого — пофиг.
И что с этим слепком содержимого кеша делать? Какая его вообще значимость может быть? Какая вероятность, что из тысячи вариантов содержимого кеша в секунду именно текуший слепок содержит хоть какуюто важную информацию?
Здравствуйте, Pzz, Вы писали:
C>>Можно организовать пробы, которые утекают по одному биту содержимого. А одного бита со сдвигом уже достаточно, чтобы получить всё остальное. В результате, память читается со скоростью 500 килобайт в секунду. Pzz>Спасибо. Pzz>Охренеть можно. А как из сделать то же самое из JS?
Не очень понял сам, если честно.
C>>Этот код, естественно, падает на SIGSEGV. Но проблема в том, что CPU успевает таки спекулятивно исполнить одну из проб. И затем с помощью тестирования кэша можно обнаружить какая проба сработала. Pzz>А кэш как тестируют? По времянке?
Да, самое простое посчитать число тактов. Но этим оно не ограничивается. Причём даже кэш не нужен, один из способов — использовать инструкции с переменным числом тактов (деление, например) и смотреть сколько тактов оно выполняется в зависимости от данных.
Здравствуйте, Grizzli, Вы писали:
G>И что с этим слепком содержимого кеша делать? Какая его вообще значимость может быть? Какая вероятность, что из тысячи вариантов содержимого кеша в секунду именно текуший слепок содержит хоть какуюто важную информацию?
Содержимое кэша пофиг. Для успешной атаки надо лишь обнаружить присутствие в кэше нужной линии. Её содержимое неважно.
Здравствуйте, Cyberax, Вы писали:
C>Стали известны детали Meltdown и Spectre. Если кратко: всё плохо.
Уже и статью запилили: https://habrahabr.ru/post/346078/
Собственно, суть атаки то очень проста и достаточно красива:
Сбрасываем кэш процессора.
Читаем интересную нам переменную из адресного пространства ядра, это вызовет исключение, но оно обработается не сразу.
Спекулятивно делаем чтение из массива, который располагается в нашем, пользовательском адресном пространстве, на основе значения переменной из пункта 2.
Последовательно читаем массив и аккуратно замеряем время доступа. Все элементы, кроме одного, будут читаться медленно, а вот элемент, который соответствует значению по недоступному нам адресу.
Таким образом, объектом атаки является микроархитектура процессора, и саму атаку в софте не починить.
Т.е. читая последовательно байт за байтом из таблицы (как понимаю размером в 256) и замеряя время доступа к каждому байту, ловят значение этого самого байта за пределами юзер спейса.
А красово, а?
Хотя конечно есть тонкости, к примеру, исключение может прийти раньше, чем таблица будет прочитана до конца. Или каждый раз надо также сбрасывать кеш, потому-что сама таблица может быть закеширована, ну и т.д.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Т.е. читая последовательно байт за байтом из таблицы (как понимаю размером в 256) и замеряя время доступа к каждому байту, ловят значение этого самого байта за пределами юзер спейса.
V>А красово, а?
Не красиво. Есть же виртуальная память и у каждого процесса она своя. Что мешает не иметь охраняемых данных в ввиртуальном адресном пространстве вообще?
Здравствуйте, kov_serg, Вы писали:
V>>А красово, а? _>Не красиво. Есть же виртуальная память и у каждого процесса она своя. Что мешает не иметь охраняемых данных в ввиртуальном адресном пространстве вообще?
Именно то, что Intel сэкономила сразу в двух местах:
1. Работа с виртуальной памятью включается/выключается для всей системы целиком, а не для отдельного режима или процесса, а пространство общее на все уровни привилегий.
Это решение ещё в i386. Позже это устраняли, но ради виртуализации и SMM. Основной же режим остался тем же. Для сравнения:
* SPARC: часть ядра принципиально может работать только при выключенной dynamic address translation (DAT). В частности, это обязательно для обработчика страничного прерывания, потому что процессор не ведёт никаких таблиц виртуальной памяти сам, отдавая это на софтовое решение.
* z/Arch: DAT включается/выключается одним битом в PSW. Ядро может использовать чисто физическую адресацию, чем и пользуются. (Тут картина смазывается виртуализацией, которая там очень эффективная, но убойно сложная. Пропустим это.)
То есть сделать правильно было можно. Не захотели.
2. Права доступа к странице проверяются только при "реализации" действия команды, но не при предвыборке с предисполнением (результаты которого ещё не фиксируются).
А вот это уже совсем кретинизм, которому исполнилось более 20 лет.
Здравствуйте, Cyberax, Вы писали:
C>Стали известны детали Meltdown и Spectre. Если кратко: всё плохо.
C>Meltdown специфичен для Intel и позволяет из userspace-процесса прочитать всю физическую память, включая ядро и гипервизор. Защита только через KAISER для Линукса ( https://lwn.net/Articles/741878/ ) или аналогичное изменение для NT. AMD не подвержен конкретно этой уязвимости.
C>Spectre является более общей уязвимостью и полной защиты от неё пока что нет.
судя по описанию, дыра на уровне процессора.
но тогда же невозможно её исправить за счет патча для ОС, нетакли?
но тогда почему к примеру MS рапортует что выпустила патч?...
Здравствуйте, Cyberax, Вы писали:
C>Да, самое простое посчитать число тактов. Но этим оно не ограничивается. Причём даже кэш не нужен, один из способов — использовать инструкции с переменным числом тактов (деление, например) и смотреть сколько тактов оно выполняется в зависимости от данных.
А часто вообще попадаются программы, которым на вполне законных основаниях надо слазить в ядерные адреса и обойтись легким SIGSEGV'ом, вместо заслуженной смерти?
