Американские исследователи из компании Third I/O на состоявшейся в Китае конференции Semicon China представили доклад, в котором рассказали о том, что уязвимости Rowhammer подвержены и чипы DDR4. Ранее считалось, что память этого типа не подвержена данной уязвимости, которую весной 2015 года обнаружили ИБ-специалисты из Google.
В чем проблема
В опубликованном в марте 2015 года описании техники эксплуатации уязвимости Rowhammer исследователи из команды Project Zero Google рассказали, что проблема заключается в изменении значений отдельных битов данных (bit flipping), хранящихся в DIMM-модулях чипов DDR3.
Память DDR представляет собой массив разбитых на блоки строк и столбцов. К ним обращаются различные приложения и операционная система. В каждом крупном участке памяти предусмотрена своя «песочница», получать доступ к которой может лишь определенный процесс или приложение.
Если запустить софт, который будет сотни и тысячи раз за долю секунды обращаться к конкретным строкам в таких участках («простукивая» их, как молотком — отсюда и название hammering), то в следствии определенных физических явлений, это может повлиять на соседний участок памяти. Это может привести к изменению значений битов в нем с нулей на единицы и наоборот.
Получив возможность влиять на содержание даже заблокированных областей памяти, злоумышленники могут осуществлять атаки, приводящие к повышению привилегий вплоть до административных. Соответственно, возможен запуск зловредного кода или перехват действий пользователей или программ.
Впоследствии другие исследователи обнаружили способ эксплуатации уязвимости Rowhammer с помощью JavaScript-кода, который использует большое количество сайтов для доставки контента пользователям. Несмотря на ограниченность этого эксплоита — он работал только на ноутбуке Lenovo x230 Ivy Bridge со стандартными настройками и чипом Haswell, примечателен сам факт программной атаки, использующей физические недостатки уязвимых DIMM.
Проблема серьезнее
Многие компании-производители чипов DDR4, такие как Micron и Samsung, заявляли о том, что их продукция не подвержена уязвимости благодаря использованию технологии TRR (Targeted Row Refresh — таргетированное обновление строк).
Исследователи из Third I/O решили проверить обоснованность этих заявлений и протестировали 12 разновидностей чипов DDR4 — и довольно быстро в 8 случаях им удалось осуществить изменение значений битов. Среди уязвимых чипов оказалась продукция Micron и Geil, а продукция G.Skill сумела выдержать тесты.
В ходе тестирования использовался созданный в Third I/O инструмент под названием Memesis, с помощью которого исследователи, в том числе, запускали большое количество процессов, работающих с одним участком памяти. В отличие от предыдущих опытов с повторением атаки Rowhammer, в этот раз исследователи «простукивали» не только области памяти, ячейки в которых содержали только нули или единицы. Им удалось разработать так называемый «дата-паттерн убийцу», который в некоторых случаях позволял повысить частоту перемен значений в битах на 50% по сравнению с другими паттернами.
В шестнадцатеричной форме он выглядит так:
492492492492492492492492492492492492492492492492
В двоичной так:
0100100100100100100100100100100100100100100100100100100100100100
1001001001001001001001001001001001001001001001001001001001001001
0010010010010010010010010010010010010010010010010010010010010010
Тесты завершались успехом также в случае DDR3-чипов с защитой от Rowhammer под названием ECC (error-correction code).
Несмотря на малую выборку чипов, исследователи убеждены, что им удалось доказать воспроизводимость атаки Rowhammer для памяти DDR4, что ранее считалось невозможным.
Не все так плохо
Несмотря на угрозы, выявленные различными исследователями за прошедший с момента обнаружения Rowhammer год, проведение подобной атаки представляет собой нелегкую задачу. Технический директор и сооснователь Third I/O Марк Лантейн (Mark Lanteigne) рассказал изданию Ars Technica, что на данный момент не существует «актуальной угрозы эксплуатации», однако в целом, существующая картинка далеко не столь безоблачна, как рисуют пресс-релизы производителей чипов.
Исследователи говорят, что цель их работы — продемонстрировать тот факт, что риск атак с использованием bit flipping является реальным. А значит, производителям чипов DDR3 и DDR4 следует уделять больше внимания безопасности своих продуктов.
Комментарии (30)
vsespb
21.03.2016 15:10+1На такой "уязвимой" памяти что выдаёт мемтест86?
kibergus
21.03.2016 23:41+2Он эту ошибку не находит. memtest пишет большие блоки памяти и сканирует её всю. А для этой ошибки удары должны быть более точечными и надо очень много раз писать строго в одни и те же ячейки памяти.
vsespb
21.03.2016 23:45Окей, но мне кажется, исходя из того, что это просто "битая память" (ну допустим большАя часть памяти таки "битая"), это прямая функция мемтеста, и его недоработка.
Regis
22.03.2016 00:38В нормальных условиях это будет воплне нормальная память, а не битая.
Для исправления "недоработки" мемтеста придется заставить его работать в экстремальном режиме как и Rowhammer. Это замедлит время работы меместа грубо говоря в миллион раз. Вам действительно нужен мемтест, который работает пару лет?vsespb
22.03.2016 00:49Почему в миллион раз? Зачем всю память так тестировать? В описании сказано что взломали довольно много систем (применительно к DDR3), значит у многих систем уязвима вся память (или больше половины, ну в общем большой процент)
Regis
22.03.2016 01:11Rowhammer долбит небольшой сегмент и следит за появлением изменений во всей зарезервированной памяти.
А вы говорите про "исправление" местеста. Если уже делать "полный" тест памяти, то нужно тестировать всю память, не так ли? сраказм
Для всех практических задач предложенное вами "исправление" мемтеста просто не имеет смысла.vsespb
22.03.2016 01:16Ну уязвимость эксплуатируется не за миллион лет. Почему бы мемтесту не попытаться проэксплуатировать её. Удалось — ошибка. Не удалось — ОК.
vsespb
22.03.2016 03:14+1а вот например есть
https://en.wikipedia.org/wiki/Memtest86
plus a new "row hammer test" based on research from Yoongu Kim et al
Psychosynthesis
21.03.2016 15:15+1А есть реальные примеры реализации подобной атаки?
Я вот вижу целую пачку потенциально непреодолимых трудностей в реализации.
Как узнать что область памяти, в которую необходимо внести изменения, физически находится рядом с той, которую мы «простукиваем»? Как узнать какие биты поменяются, а какие нет? Смена пары битов приведёт к повышению привелегий? Ну и т.д…
Я может не очень хорошо понял механизм уязвимости, но если проблема в физической близости (одна «строка» памяти) уязвимых блоков к простукиваемым блокам, то почему бы просто не организовывать некую «буферную зону» вокруг важных ячеек, дабы их нельзя было подобным образом менять?
Alexeyslav
21.03.2016 16:35А какие ячейки назвать важными? Программа может получить от чипов памяти достаточную информацию чтобы выяснить её организацию и применить нужный алгоритм. Это конечно будет довольно сложно, но моделей чипов памяти ограниченное количество.
Самая простая защита от этой фигни — на материнке по разному разводить шины адреса и данных. А сами чипы производить со случайным распределением шин данных в каждой странице памяти. Это сильно снизит результативность атаки, и скорей будет приводить к повреждению соседних областей памяти что может приводить к многочисленным аппаратным ошибкам и не может остаться незамеченным.
Кстати дополнительным противодействующим фактором может выступить неизвестное программе распределение ячеек по каналам контроллера памяти когда модуля памяти может быть не один а два или три работающих в многоканальном режиме.Zolg
21.03.2016 18:30а сами чипы производить со случайным распределением шин данных в каждой странице памяти
Ого! А не разумней ли усилия направить на устранение бага в чипах, могущего доставлять неприятности помимо безопасности.Alexeyslav
22.03.2016 00:06Судя по тому что баг не исправили — это чрезвычайно трудно и граничит с фундаментальной проблемой. Например, проблема обусловлена плотностью ячеек… и единственный способ её решить это снизить плотность ячеек, т.е. откатится в ёмкости чипа назад…
Конечно, подробностей мало озвучивают почему это происходит… было бы интересно узнать а пока остаётся только строить догадки.Zolg
22.03.2016 12:00Исправлять баг можно по разному.
У нанд флеша, например, тоже есть фундаментальные проблемы, однако контроллеры с ними успешно борются (хотя на низком уровне проблемы никуда не исчезают).
Чипы со случайным распределением шин на кристалле это security through obscurity, сама проблема при этом остается на месте. При этом производить фактически 100500 разных (пусть и в мелочах) кристаллов может оказаться удовольствием более дорогим, чем даже просто тупо зафигачивать больше битов под ECC.Alexeyslav
22.03.2016 12:19Однако, это позволит снизить процент успешности атаки и повысить её стоимость. Что вобщем-то тоже было бы неплохо, как дополнительный эшелон в рамках общей системы защиты.
gearbox
21.03.2016 17:46может не очень хорошо понял механизм уязвимости
Это разновидность глич-атаки (Differential Fault Analysis, DFA), первыми заявили в BellCore, затем Ади Шамир и Эли Бихам развили. если мне не изменяет память, Шамир нагреванием вскрывал то ли симки то ли чипы кредиток — при желании можно нагуглить.
GAS_85
21.03.2016 15:34-40100100100...
Почти угадали
en1gma
21.03.2016 21:29+5Тесты завершались успехом также в случае DDR3-чипов с защитой от Rowhammer под названием ECC (error-correction code).
чего-чего?Alexeyslav
22.03.2016 00:11В принципе так и есть, если мы меняем посторонние биты в обход ECC то рано или поздно при считывании модифицированной ячейки с высокой вероятностью обнаружим ошибку чётности...
nerudo
Это уже не безопасность, а попросту работоспособность. В таких условиях никто уже не может гарантировать, что нормально функционирующая пользовательская программа не произведет подобного же разрушения содержимого памяти.
kibergus
А вот и нет. Почитайте исходную статью от гугла. Там применяются очень красивые приемы, чтобы случайные изменения битов сначала использовать для выхода из песочница native client, а затем чтобы повысить себе привелегии и писать и читать произвольные места в памяти.
kibergus
Если кратко, то аллоцируем кучу страниц памяти. RAM забивается вашими страницами и страницами ОС с TLB. В TLB хранятся записи о том, какие страницы памяти вы можете читать и писать. Дальше молотим память. Какие-то биты меняются. Это с большой вероятностью биты либо в ваших страницах, либо в TLB (потому что это большая часть страниц в системе). Если в ваших страницах, то они ничего не рушат. Если в TLB, то с большой вероятностью это биты в адресах страниц, к которым у вас есть доступ (потому что все TLB забиты записями о ваших страницах, которых наплодили на первом этапе). Теперь смотрим, что хранится в наших страницах. В результате того, что мы молотили по памяти и адрес в TLB поменялся ваш процесс мог получить доступ к какой-нибудь другой странице памяти. С большой вероятностью к своей собственной или (с меньшей вероятностью) к TLB (так как TLB страниц тоже много). Во втором случае у нас появиласьвозможность писать в TLB. Но это значит, что мы можем разрешить себе читать и писать в любую угодную нам страницу памяти.
ion2
TLB ( translation lookaside buffer) или всё же таблицы страниц? Первое — часть процессора и к ошибкам в модулях памяти отношения не имеет.
kibergus
Таблицы страниц, я неправильно употребил термин.
kibergus
Это тоже не совсем так. Чтобы воспроизвести ошибку надо максимально часто писать в одни и те же ячейки памяти. В обычной программе в такой ситуации работет кеш процессора, поэтому реальная запись в оперативную память происходит редко. Для того, чтобы rowhammer проявился после каждой операции записи производится принудительный сброс данных из кеша CPU в оперативную память. Нормальные программы так не делают.