![](https://habrastorage.org/webt/tu/do/kg/tudokgm_v7oifllwhpb2gwrgwxq.png)
Примерно так выходит с уязвимостями класса Rowhammer. Четыре года назад была обнаружена принципиальная возможность изменить «соседний» бит в модуле оперативной памяти регулярными операциями чтения/записи. С тех пор появились новые исследования, показывающие, как применить эту особенность плотно упакованных чипов памяти для практических атак. На прошлой неделе сборная команда ученых из разных стран показала практическую атаку на Android-смартфоны RAMpage (новость, исследование). Насколько эта атака реально опасна? Попробуем разобраться (спойлер: пока непонятно).
Напомню, атака Rowhammer использует фундаментальные особенности чипов памяти. Конкретно, изменение заряда при записи в определенную ячейку (точнее, ряд ячеек) влияет и на соседние ячейки (ряды) тоже. Обычно это не представляет проблемы, так как через определенные промежутки времени заряды во всех ячейках обновляются. Но если достаточно часто и много производить операции чтения-записи (десятки и сотни тысяч раз), можно изменить значение в ячейках памяти, к которым у вас изначально не было доступа (все написанное выше — вульгарное упрощение, граничащее с криминалом, а истина содержится только в оригинальной научной работе). Приспособить данную особенность памяти для какой-нибудь реальной атаки непросто: требуется правильная комбинация прав доступа к системе, расположения кода в памяти, прямой доступ к памяти без кэширования и прочая, и прочая. Не сразу, но за четыре года набралось немало примеров таких комбинаций, и Rowhammer из милой теории превратился в суровую практику.
![](https://habrastorage.org/webt/pt/wn/7k/ptwn7kv724_pndavvowmlfzty7i.jpeg)
Когда нужна картинка про компьютеры, молотки и безопасность
Не буду даже пытаться пересказать простыми словами атаку RAMpage. Эта атака обходит заплатки, внедренные в Android после обнаружения (примерно той же группой исследователей) атаки Drammer в 2016 году. Комбинация нескольких ранее известных методов, обеспечивающих прямой доступ к оперативной памяти в нужном месте, и особенностей современной версии Android (в эксперименте использовался телефон LG G4 с Android 7.1.1) позволила получить права суперпользователя на полностью запатченном телефоне.
Что нехарактерно для исследования по новой уязвимости, авторы RAMPage предлагают также способ закрыть уязвимость, причем с весьма небольшим падением производительности (по версии Google, падение там все же значительное). Более того, митигация (ей тоже придумали имя — GuardION) позволяет включить обратно оптимизации, выключенные в Android после предыдущего исследования.
![](https://habrastorage.org/webt/gd/ai/fe/gdaifelsbejlg6ccdxykjzwb8sc.png)
В лучших традициях современного vulnerability marketing уязвимости (и заплатке) сделали сайт и логотипы. Но так как это ученые, FAQ на этом сайте предельно честный: «Нет, это не Spectre, даже не рядом». «Нет, мы не покажем вам PoC». «Мы не знаем, подвержен ли ваш телефон
Что, если выражаться обычным русским языком, произошло? Исследователи чуть-чуть подняли планку практичности еще одной атаки, использующей аппаратную уязвимость. Ее пока не применяет (и вряд ли будет) криминал, и вообще от состояния «получили рут в лаборатории» до «можем атаковать значительное количество устройств реальных пользователей» путь неблизкий. Google в курсе, и каким-то образом хотя бы в новых версиях Android держит проблему под контролем. Такие исследования требуют много времени, а опасность заключается в возможном резком переходе из количества (потраченных человеко-часов) в качество. А именно: в появление какой-нибудь относительно легко (хотя бы как Meltdown) эксплуатируемой дыры, закрыть которую можно или покупкой нового устройства, или падением производительности в разы.
Впрочем, предложение выше — это уже неосторожное допущение (но автору текста можно, он не ученый). Тем временем другая группа исследователей вроде бы нашла еще одну аппаратную уязвимость, на сей раз в функции hyperthreading в процессорах Intel. Более того, уязвимость была применена для кражи ключа шифрования из процесса, выполняющегося в соседнем «треде» того же ядра. А мейнтейнеры OpenBSD были настолько впечатлены результатами, что решили выключить поддержку функциональности процессоров в дистрибутиве полностью (с очевидными последствиями для производительности). Исследовательская работа планируется к публикации на конференции Black Hat в августе. Продолжаем наблюдение.
Disclaimer: