На проходившей с 1 по 4 ноября в Лондоне конференции Black Hat Europe австрийские исследователи представили новую атаку, использующую особенности реализации взаимодействия CPU с DRAM. Метод позволяет злоумышленникам с помощью JavaScript красть чувствительную информацию прямо из виртуальных машин. Атака получила название DRAMA.
Как это работает
Исследователи Андерс Фог (Anders Fogh) и Михаэль Шварц (Michael Schwarz) в ходе своего выступления продемонстрировали несколько кросс-процессорных атак. Первая часть их исследования была представлена на мероприятии USENIX Security Symposium в августе этого года.
На Black Hat авторы показали, как злоумышленники с помощью JavaScript могут перехватывать небольшие «порции» чувствительных данных, вроде паролей или приватных ключей, из виртуальных машин, которые даже не подключены к сети.
Существует два сценарии развития атаки:
- В первом случае два процесса — в виртуальной машине и в основной системе — могут общаться друг с другом.
- Во втором — один процесс может следить за адресами памяти, который использует другой.
Рассмотрим первый сценарий. Цель атаки в данном случае заключается в передаче данных из виртуальной машины (ВМ), не имеющей доступ к сети, в основную систему (ОС), откуда злоумышленник уже скачивает ее по сети.
Это возможно благодаря особенности устройства памяти DRAM — в частности тому, что процесс-отправитель (находящийся в ВМ) и процесс-получатель данных (в ОС) используют адреса памяти, находящиеся в одном банке памяти (DRAM bank). Механизм работает таким образом, что в том случае, если процесс недавно работал с памятью из определенного банка, то повторные обращения будут проходить быстро.
Если отправитель работал с памятью между двумя обращениями получателя, то второе обращение займет больше времени — это будет интерпретировано как бит 1. В том случае, если отправитель не работал с памятью в промежуток между двумя обращениями, этот факт будет обозначен как 0.
Главная задача здесь — получить адреса в общем банке памяти (или нескольких банках для ускорения процесса) и верно определить временные точки для взаимодействия двух процессов. Для ее решения авторы использовали особенности работы многих современных систем — например, в них часто используются большие страницы памяти (>2 МБ) и определенная частота опроса адреса (на стороне получателя), которая превышает частоту записи (на стороне отправителя) в несколько раз. Зная это исследователи смогли построить предположения о поведении целевой системы.
Во втором сценарии для атаки используется способ, похожий на атаки с использованием особенностей работы кэш-памяти процессора. Суть метода заключается в том, что зная, какие адреса использовал процесс, можно наблюдать за введёнными в него данными — например, адресом сайта, который пользователь ввёл в адресную строку браузера.
Нет простых способов защиты
Исследователям удалось разработать атаку, для проведения которой не требуется эксплуатация каки-либо уязвимостей или запуск вредоносного софта на хост-системе. Они просто открывают скрытый канал между виртуальной машиной и основной системой.
При этом, Фог и Шварц признают, что атака может не всегда осуществляться корректно — в некоторых случаях используемая для фильтрации данных память может быть занята другими приложениями, что не позволит передать информацию из виртуальной машины, однако вероятность такого исхода не очень велика.
Исследователи фокусировались на тестировании своего метода атаки на платформе Intel x86-64, однако им удалось выяснить, что другие архитектуры — например, ARM-процессоры в смартфонах — также уязвимы
Поскольку разработанная атака использует особенности механизма DRAM, простых способов противодействия ей не существует, уверены исследователи. Тем не менее, они не прогнозируют большого числа подобных атак в реальных системах в ближайшие годы. Но сама вероятность таких атак показывает, что разработчикам нужно повышать защищенность не только софта, но и само «железо».
Комментарии (16)
Konachan700
10.11.2016 12:22-2Про жаваскрипт добавили журналисты скорее всего, чтобы страху напустить.
Если я правильно понял, это старый трюк с освобожденной памятью. Если агрессивно делать выделение памяти небольшими кусками, забивая все под ноль, то произойдет вытеснение части неактивных приложений в своп и их «старая» память очищена не будет — с какой-то вероятностью весь чужой хлам окажется в неинициализированной памяти у нас в программе. Дальше просто читаем куски этой памяти и ищем там что-нибудь полезное. Реальной пользы от трюка ноль, хотя на специально подготовленном стенде будет выглядеть как крутое колдунство.
Зачем нужно считать реальные адреса вообще непонятно, они же бесполезны в данном случае…mayorovp
10.11.2016 13:38+1Этот баг давно исправили во всех приличных ОС и гипервизорах. К слову, это была очень серьезная проблема безопасности, а не "трюк".
michael_vostrikov
10.11.2016 13:48Похоже, что нет. Принцип действия описан в пункте 5.1 pdf-файла. Как я понял, смысл в том, что можно передавать данные из виртуальной машины на хост без сети или общей памяти. То есть, надо иметь 2 своих процесса в ВМ и на хосте. Они выделяют себе какое-то количество памяти, некоторые страницы оказываются в одном банке памяти, но в разных строках. Как это определить, описано в первой половине документа. Процесс-получатель постоянно обращается к выбранному адресу и меряет время доступа. Если процесс-отправитель тоже будет обращаться к странице в этом же банке памяти, но в другой строке, то будет конфликт строк, и время доступа в процессе-получателе увеличится. Меняя время доступа, можно передавать биты.
novoxudonoser
10.11.2016 16:08-1Решение тут может быть, правда оно так себе — виртуальная машина в виртуальной машине.
sebres
10.11.2016 21:50Глупости не говорите: универсальное решение тут может быть только одно, в маппере чистить сегмент (нулями) как минимум за пределы реального перетащенного блока до размера сегмента банки, и как максимум по выделению и перед перетаскиванием блоков), что есть 1. геморрой, 2. вымывает кэша, 3. нереально "ускоряет" контекст-свич туды-сюды, ну и все сопутствующее безобразие в придачу сверху (сброс TLB, глобальных дескрипторов и т.д. и т.п.).
Ну или экзотика типа той же CBA (capability-based адресация), что тоже нереально весело, т.к. нужно будет переписать все, начиная от компиляторов и заканчивая ядром ОС и гипервизоров…
И последствия сего — бинарная (не)совместимость такого софта к примеру, тоже имеют место.
Одно вот только (что бы значит чуть сбавить градус истерии) — как применить на практике подобную "уязвимость" не ясно даже самим "первооткрывателям"… Ну и сколько звезд на небе для этого должны сойтись, история по видимому умалчивает...
iCpu
11.11.2016 05:58Универсальное решение действительно только одно — физическое разнесение систем по разным банкам\планкам\машинам, и разным ядрам\камням\машинам, и разным дискам\рейдам\машинам. Потому что перестукивание высокой нагрузкой может происходить по любому бутылочному горлышку, коих у компьютера бесконечное счётное множество. То же самое перестукивание можно производить по шинам ввода-вывода, по загрузке процессора и даже, простите за вульгарности, режиму энергосбережения.
Единственное железобетонное решение проблемы — полностью изолированная машина, замурованная в тот самый железобетон. Не самое удобное, впрочем.
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. Так что всё пока есть.