SadKo, Перечитайте, у вас ошибочные понятия. В нт через данный механизм можно только ядро прочитать(изоляция задач), в никсах все приложения доступны. Это из за разной архитектуры - в нт она есть, поэтому и не уязвима, а для никсов это полный ппц такая атака. То что вам нравится софт для написания музыки на никсах ничего не значит.
прикол в том, что эта МЕЛОЧЬ позволяет слить ключи и пароли. А работать скрытно на машине жертвы способна месяцы/годы. и, что примечательно, снифер может себя успешно показывать даже из-под виртуалок. самый надёжный способ борьбы == отказаться от всех бустеров проца.. 1. 3oe == out-of-order execution. 2. спекулятивка. 3. да-да, кэш проца тоже нужно отрубать. === ща все заинтересанты слабали/лабают себе киты для снифа.. а в паблике имеют место быть лишь отголоски. --- Сообщение объединено, 10 дек 2018 --- изоляция задач идёт на уровне озу, а когда данные попадают в кэш проца, то вся та изоляция йдёт Лесом-де Садом --- Сообщение объединено, 10 дек 2018 --- а что за хостовая ось у тебя? виртуалбокс пашет под линем вполне годно.
UbIvItS, > когда данные попадают в кэш проца, то вся та изоляция йдёт Лесом-де Садом Это не так, это только в никсах. Нт устроено на механизмах изоляции, каждый доступ к обьекту требует соответствующих прав и действий. Так например память иного процесса не существует, к ней нужно выполнить аттачь(присоедениться на уровне транслятора памяти), только так переключив адресное пространство можно работать с памятью процесса и только одного. Из юм это сделать невозможно, можно лишь вызывать сервисы для работы с процессами, к примеру они прочитают память через смену ап, да и только после прохода защитных механизмов. Кэш сбрасывается планировщиком при переключении на новую задачу. Я же дал ссылку, курите. Даже часть ядра не доступна для самого ядра, это сессионное пространство, к нему нужно выполнять авторизованный аттачь
так какой смысл в кэше, если его постоянно нулить??? к тому же, такой подход не совсем задачу решает: ведь, в системе-то одновременно работает куча потоков
Да конечно, НТ спасёт от того, что проц помещает данные в кэш перед тем, как проверить права доступа. Ну не говорите ерунды. Везде, где есть спекулятивка, есть потенциальная угроза. Даже некоторые процессоры ARM уязвимы из-за наличия в них instruction reordering.
в сущности все гламурные процы дырявенькие, то бишь все настольные пк/лэптопы/гаджеты/.. кстати, очень уязвимы именно сервачные процы, пч там увеличенный размер кэша и данные в итоге могут там дольше валяться. Но самое забавное, что проблема будет лишь маскироваться и на реальное решение никто не пойдёт. Ибо на защищённой электроники сделать облачка и даже просто поддержать современные скорости инета совершенно невозможно
SadKo, > Ну не говорите ерунды. Ну раз я говорю ерунду, то докажите семплом, верно? зачем тогда спорить. Раз вам теории мало и вы ей не доверяете, то тогда посмотрим на практике.
сорцев не дам (во всяком случае пока), но маленько расписать схему снифа можно он работает в два хода.. ПЕРВЫЙ. выявляет само наличие целевой переменной в кэше.. на этом останавливаться не будем, ибо достаточно тривиально. ВТОРОЙ. считываем содержимое целевой переменной из кэша. схематично примерно так.. Код (C): int content[10], getIt; time_t time, theshold; setAcceptedLag4Op(&threshold); for i, 0..63 startClock(); for j, 0..9999 if content[X] < 10 { // enter the shadow if (content[X] >>i) & 1 == 1 { // do something } } end for endClock(); getTime4Op(&time); if time < threshold { setBit(i, &getIt); } end for когда конвейер встречает if, то получаем три потока.. 1. высчитывает условие у ветвления. 2. бежит по теневой ветке. 3. по белой. ====== как только условие посчитано, рубится теневая ветка. То бишь в тени у нас имеется возможность прокатить где-то 3-7 асм команд. при этом для растягивания удовольствия у нас имеются целых три механизма.. 1. 3oe (out-of-order exec). 2. тормозим вычисление условия для ветвления. 3. параллелим. ==== короче, под задачу и проц. пилим сниф. а основной задачей является увод ключей и паролей, ибо.. 1. очень хорошо, чтоб в кэш ронялись константы. 2. пароли и ключи (того же рса) наиболее ценны в плане слома сервача, организации фишинга итд-итп.
Rel, > Инде просто надо пойти матчасть подучить... Прочтение не изменит результат прошлых тестов. Зачем мне всякий спам и рекламу читать. Вы привели список железок, а где примеры и статистика по каждой из них, причём есчо и под всю линейку нт и не только под эту ос ? В мс палитика такая - если даже есть какая то сомнительная вероятность уязвимости - разрабатывать механизмы противодействия и апдейтить всё, даже если это не может работать принципиально. Просто там спецов и прочих ресурсов достаточно что бы такое делать.
нельзя хардварную дыреньку закостылять софтинкой. --- Сообщение объединено, 12 дек 2018 --- if X < 10
UbIvItS, > нельзя хардварную дыреньку закостылять софтинкой. Вам привести пример/комменты; в врк, там какой то косяк был с ловушками на пне), я не помню точно, но ведь фиксится!?
ну, можно тотально нулить кэш для каждого потока в системе, а толку-то с того??? лучше уж хардваарно обрубить все плюшки проца по бусту и работать система будет шустрей, чем "решения" чрез софтварные костыли. Да, и в сущности сама по себе трабла багом не является, тч понятие "исправление ошибок" тут совсем левое. корпи тогда (где-то к середине нулевых) встали пред fuct'm, что легальный буст процев стал физически невозможен.. сначала была мысля соорудить предсказатель ветвлений, но от неё быстро отказались, ибо оверхед промахов сжирал все попадания и проц пахал заметно тормознутей. Поэтому быстро пришли к идее теневых команд без проверок прав на доступ, ну и отсюда выросли спекулятивка с внеочередным исполнением команд + минимум обнулений кэша и скрытых (в некоторых случаях векторных тоже) регистров. в итоге получился весь этот шустрый гламур, но шило в мешке утаить было невозможно тоже теперь же вся ся смешная возня по "лечению" проблемы не более, чем пыль в глаза. впрочем, справедливости ради стоит отметить, что особо шустрый сниф получить едва ль возможно, что существенно снижает возможности уноса данных. опять же повторюсь, речь в основном идёт о снифе констант, а с переменными данными слишком много мусора.
кстати, очень любопытно-забавный момент имеется в плане теневого перемещения данных == их АКЬ МИНИМУМ в тихую можно запихнуть в кэш: обычно мусор от теневых операций не обнуляется, его по ходу рантайма вытесняют более актуальные данные. Но при этом ничего не мешает форсировать теневую подгрузку в цикле.
UbIvItS, Даже если какой то способ чтения памяти ядра(mm disclosure) работает, то это обычно бесполезно. Там не хранятся важные данные в открытом виде. На них нужно как то указатели определить, дёрнуть ядерный апи, который транслирует описатели в адреса и тп.
Indy_, для практического взлома ядро == последняя из разумных целей. основная цель == получить руту. На крайняк доступ к мало-мальски значимому акку.