Забавные новости 0й-Ti :)

SadKo,

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

 

прикол в том, что эта МЕЛОЧЬ позволяет слить ключи и пароли. А работать скрытно на машине жертвы способна месяцы/годы. и, что примечательно, снифер может себя успешно показывать даже из-под виртуалок. самый надёжный способ борьбы == отказаться от всех бустеров проца..

1. 3oe == out-of-order execution.
2. спекулятивка.
3. да-да, кэш проца тоже нужно отрубать.
===
ща все заинтересанты слабали/лабают себе киты для снифа.. а в паблике имеют место быть лишь отголоски.

--- Сообщение объединено, 10 дек 2018 ---

изоляция задач идёт на уровне озу, а когда данные попадают в кэш проца, то вся та изоляция йдёт Лесом-де Садом

--- Сообщение объединено, 10 дек 2018 ---

а что за хостовая ось у тебя? виртуалбокс пашет под линем вполне годно.

 

Намекаете на арифметику указателей?

 

UbIvItS,

> когда данные попадают в кэш проца, то вся та изоляция йдёт Лесом-де Садом

Это не так, это только в никсах. Нт устроено на механизмах изоляции, каждый доступ к обьекту требует соответствующих прав и действий. Так например память иного процесса не существует, к ней нужно выполнить аттачь(присоедениться на уровне транслятора памяти), только так переключив адресное пространство можно работать с памятью процесса и только одного. Из юм это сделать невозможно, можно лишь вызывать сервисы для работы с процессами, к примеру они прочитают память через смену ап, да и только после прохода защитных механизмов. Кэш сбрасывается планировщиком при переключении на новую задачу. Я же дал ссылку, курите.
Даже часть ядра не доступна для самого ядра, это сессионное пространство, к нему нужно выполнять авторизованный аттачь

 

так какой смысл в кэше, если его постоянно нулить??? к тому же, такой подход не совсем задачу решает: ведь, в системе-то одновременно работает куча потоков

 

Да конечно, НТ спасёт от того, что проц помещает данные в кэш перед тем, как проверить права доступа.
Ну не говорите ерунды.
Везде, где есть спекулятивка, есть потенциальная угроза. Даже некоторые процессоры ARM уязвимы из-за наличия в них instruction reordering.

 

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

 

SadKo,

> Ну не говорите ерунды.

Ну раз я говорю ерунду, то докажите семплом, верно? зачем тогда спорить. Раз вам теории мало и вы ей не доверяете, то тогда посмотрим на практике.

 

Я, пожалуй, оставлю это на откуп людям, которые этим занимаются: https://meltdownattack.com/

 

Инде просто надо пойти матчасть подучить...

 

Из PAPER'а по SPECTRE:

 

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

ПЕРВЫЙ.

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

ВТОРОЙ.

считываем содержимое целевой переменной из кэша. схематично примерно так..

Код (C):

1. int content[10], getIt;
2. time_t time, theshold;
3. setAcceptedLag4Op(&threshold);
4. for i, 0..63
5. startClock();
6.     for j, 0..9999
7. if content[X] < 10 { // enter the shadow
8.          if (content[X] >>i) & 1 == 1 {
9.            // do something
10.         }
11. }
12.    end for
13. endClock();
14. getTime4Op(&time);
15. if time < threshold {
16. setBit(i, &getIt);
17. }
18. 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_, для практического взлома ядро == последняя из разумных целей. основная цель == получить руту. На крайняк доступ к мало-мальски значимому акку.