DRAMA: Новая атака позволяет скрытно похищать данные из изолированных виртуальных машин

[thedsi666]

В примере, где передаются данные из глухой ВМ в браузер на хосте: каким образом между отправителем и получателем согласовывается используемый банк памяти? Если нативному процессу внутри ВМ еще может быть реально получить карту трансляции виртуальных адресов (а также получить доступ к каким-то определенным страницам), то как это сделать со стороны JavaScript?

[iCpu]

Evict
Суть простая, выделяем кучу памяти размерами не кратными размеру строки банка памяти, но кратными размеру блока, запрещаем её кешировать и считываем попарно. Если чтение произошло быстрее, значит память была с одном банке, и чем быстрее, тем ближе ряды. По списку виртуальных адресов и статистике обращений хитро получаем все соответствия между виртуальной и реальной памятью (через брутфорс). Имея список соответствий, можем делать много разных злых вещей. Перехватывать только что освободившиеся банки. Последние мосты ради ускорения делят поровну строки физической памяти на блоки по одному на процессор, так что можно словить джекпот, если считать память.

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

[mikhanoid]

А как прочитать блок чужой физической памяти? Типа, ОС у нас до этого взломана и позволяет mmap-ить всё, что угодно, куда угодно? Но если ОС взломана, то зачем страдать, когда можно просто получить всю раскладку памяти стандартными способами?

[iCpu]

Чисто теоретически? Вызвать перераспределение физической памяти каким-либо способом и попытаться realloc-нуть массив в то место, где был интересующий процесс.
Практически? Я сам дико сомневаюсь, что подобная уязвимость может работать за пределами тестового стенда. И причина не только во всех уровнях защиты, для корректной работы загруженность сервера должна быть минимальна, иначе подсчёт времени будет слишком зашумлен. Какой разумный человек оставит сервер без нагрузки?

[mayorovp]

Не получится realloc-нуть. Независимо от виртуального адреса, ОС выделяет "реальные" страницы из своего пула, и нет способа запросить конкретную. А потом гипервизор выделит страницу для ОС — и тоже нет способа запросить конкретную. Кроме того, раз уж мы говорим про javascript — то тут и realloc-то недоступен.

[iCpu]

Я смутно знаком с такими шаманствами, но они выложили исходники в репу
https://github.com/IAIK/drama

Если вы сможете их проверить на работоспасобность и проанализировать на тему необходимых прав, буду очень благодарен. На моих форточках этот ужас предсказуемо не работает.

[mayorovp]

Ну, там все написано на Си, причем используется чтение из /proc/self/pagemap (наверное, это даже root-прав требует).

И еще есть такой вызов как mmap на 70% доступной физической памяти.

То есть никакого "похищения данных через javascript" там не показано.

[iCpu]

Получается, опять «учёные изнасиловали журналиста»? И почему я ни капельки не удивлён?

[bitterman]

в начале статьи есть ссылка на PDF презентации, где обсуждался именно Javascript, под названием «DRAMA: How your DRAM becomes a security problem». Судя по слайдам «DEMO», может появиться запись с конференции, где уязвимость продемонстрирована именно в сочетатнии с Javascript. Так что всё пока есть.

[mayorovp]

Этот баг давно исправили во всех приличных ОС и гипервизорах. К слову, это была очень серьезная проблема безопасности, а не "трюк".

[michael_v89]

Похоже, что нет. Принцип действия описан в пункте 5.1 pdf-файла. Как я понял, смысл в том, что можно передавать данные из виртуальной машины на хост без сети или общей памяти. То есть, надо иметь 2 своих процесса в ВМ и на хосте. Они выделяют себе какое-то количество памяти, некоторые страницы оказываются в одном банке памяти, но в разных строках. Как это определить, описано в первой половине документа. Процесс-получатель постоянно обращается к выбранному адресу и меряет время доступа. Если процесс-отправитель тоже будет обращаться к странице в этом же банке памяти, но в другой строке, то будет конфликт строк, и время доступа в процессе-получателе увеличится. Меняя время доступа, можно передавать биты.

[novoxudonoser]

Решение тут может быть, правда оно так себе — виртуальная машина в виртуальной машине.

[mayorovp]

И чем же это поможет?

[sebres]

Глупости не говорите: универсальное решение тут может быть только одно, в маппере чистить сегмент (нулями) как минимум за пределы реального перетащенного блока до размера сегмента банки, и как максимум по выделению и перед перетаскиванием блоков), что есть 1. геморрой, 2. вымывает кэша, 3. нереально "ускоряет" контекст-свич туды-сюды, ну и все сопутствующее безобразие в придачу сверху (сброс TLB, глобальных дескрипторов и т.д. и т.п.).
Ну или экзотика типа той же CBA (capability-based адресация), что тоже нереально весело, т.к. нужно будет переписать все, начиная от компиляторов и заканчивая ядром ОС и гипервизоров…
И последствия сего — бинарная (не)совместимость такого софта к примеру, тоже имеют место.

Одно вот только (что бы значит чуть сбавить градус истерии) — как применить на практике подобную "уязвимость" не ясно даже самим "первооткрывателям"… Ну и сколько звезд на небе для этого должны сойтись, история по видимому умалчивает...

[iCpu]

Универсальное решение действительно только одно — физическое разнесение систем по разным банкам\планкам\машинам, и разным ядрам\камням\машинам, и разным дискам\рейдам\машинам. Потому что перестукивание высокой нагрузкой может происходить по любому бутылочному горлышку, коих у компьютера бесконечное счётное множество. То же самое перестукивание можно производить по шинам ввода-вывода, по загрузке процессора и даже, простите за вульгарности, режиму энергосбережения.

Единственное железобетонное решение проблемы — полностью изолированная машина, замурованная в тот самый железобетон. Не самое удобное, впрочем.