Исследование: Считавшаяся «неуязвимой» память DDR4 подвержена уязвимости Rowhammer



    Американские исследователи из компании 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 следует уделять больше внимания безопасности своих продуктов.
    Positive Technologies
    175.16
    Company
    Share post

    Comments 30

      +7
      Это уже не безопасность, а попросту работоспособность. В таких условиях никто уже не может гарантировать, что нормально функционирующая пользовательская программа не произведет подобного же разрушения содержимого памяти.
        +1
        А вот и нет. Почитайте исходную статью от гугла. Там применяются очень красивые приемы, чтобы случайные изменения битов сначала использовать для выхода из песочница native client, а затем чтобы повысить себе привелегии и писать и читать произвольные места в памяти.
          +3
          Если кратко, то аллоцируем кучу страниц памяти. RAM забивается вашими страницами и страницами ОС с TLB. В TLB хранятся записи о том, какие страницы памяти вы можете читать и писать. Дальше молотим память. Какие-то биты меняются. Это с большой вероятностью биты либо в ваших страницах, либо в TLB (потому что это большая часть страниц в системе). Если в ваших страницах, то они ничего не рушат. Если в TLB, то с большой вероятностью это биты в адресах страниц, к которым у вас есть доступ (потому что все TLB забиты записями о ваших страницах, которых наплодили на первом этапе). Теперь смотрим, что хранится в наших страницах. В результате того, что мы молотили по памяти и адрес в TLB поменялся ваш процесс мог получить доступ к какой-нибудь другой странице памяти. С большой вероятностью к своей собственной или (с меньшей вероятностью) к TLB (так как TLB страниц тоже много). Во втором случае у нас появиласьвозможность писать в TLB. Но это значит, что мы можем разрешить себе читать и писать в любую угодную нам страницу памяти.
            0
            TLB ( translation lookaside buffer) или всё же таблицы страниц? Первое — часть процессора и к ошибкам в модулях памяти отношения не имеет.
              0
              Таблицы страниц, я неправильно употребил термин.
            +1
            что нормально функционирующая пользовательская программа не произведет подобного же разрушения содержимого памяти.

            Это тоже не совсем так. Чтобы воспроизвести ошибку надо максимально часто писать в одни и те же ячейки памяти. В обычной программе в такой ситуации работет кеш процессора, поэтому реальная запись в оперативную память происходит редко. Для того, чтобы rowhammer проявился после каждой операции записи производится принудительный сброс данных из кеша CPU в оперативную память. Нормальные программы так не делают.
              0
              В докладе про rowhammer написано, что впервые они столкнулись с этой проблемой на серверах при большом количестве DMA запросов, вызванных их Fibre Channel хранилищем. Так что не только сброс кеша может вызвать сбои.
            +1
            На такой "уязвимой" памяти что выдаёт мемтест86?
              +2
              Он эту ошибку не находит. memtest пишет большие блоки памяти и сканирует её всю. А для этой ошибки удары должны быть более точечными и надо очень много раз писать строго в одни и те же ячейки памяти.
                0
                Окей, но мне кажется, исходя из того, что это просто "битая память" (ну допустим большАя часть памяти таки "битая"), это прямая функция мемтеста, и его недоработка.
                  0
                  В нормальных условиях это будет воплне нормальная память, а не битая.

                  Для исправления "недоработки" мемтеста придется заставить его работать в экстремальном режиме как и Rowhammer. Это замедлит время работы меместа грубо говоря в миллион раз. Вам действительно нужен мемтест, который работает пару лет?
                    0
                    Почему в миллион раз? Зачем всю память так тестировать? В описании сказано что взломали довольно много систем (применительно к DDR3), значит у многих систем уязвима вся память (или больше половины, ну в общем большой процент)
                      0
                      Rowhammer долбит небольшой сегмент и следит за появлением изменений во всей зарезервированной памяти.

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

                      Для всех практических задач предложенное вами "исправление" мемтеста просто не имеет смысла.
                        0
                        Ну уязвимость эксплуатируется не за миллион лет. Почему бы мемтесту не попытаться проэксплуатировать её. Удалось — ошибка. Не удалось — ОК.
                          0
                          Вопрос: что именно вы хотите протестировать мемтестом?

                          То, что первый попавшийся набор сегментов узязвим (как Rowhammer) или что вся память (все возможные сегменты и их разные комбинации) не имеют узявимости (миллионы лет)?
                            0
                            Первый попавшийся.
                              0
                              Окей. Пусть memtest протестирвовал первый попавшийся сегмент (по методу RowHammer). Тест показал, что проблема не воспроизвелась (на данном сегменте). Какие выводы может сделать memtest? Что память не подвержена проблеме? Но это ведь будет неправда.
                                0
                                Кто сказал что парадигма такая? Может парадигма — либо вся память подвержена, либо нет (на это намекает что уязвимость эксплуатируют, значит часто натыкаются на память где найти проблемное место не составляет труда). К тому же выясняется что в memtest это таки есть: https://habrahabr.ru/company/pt/blog/279749/#comment_8813831
                  +1
                  а вот например есть
                  https://en.wikipedia.org/wiki/Memtest86

                  plus a new "row hammer test" based on research from Yoongu Kim et al
                +1
                А есть реальные примеры реализации подобной атаки?

                Я вот вижу целую пачку потенциально непреодолимых трудностей в реализации.

                Как узнать что область памяти, в которую необходимо внести изменения, физически находится рядом с той, которую мы «простукиваем»? Как узнать какие биты поменяются, а какие нет? Смена пары битов приведёт к повышению привелегий? Ну и т.д…

                Я может не очень хорошо понял механизм уязвимости, но если проблема в физической близости (одна «строка» памяти) уязвимых блоков к простукиваемым блокам, то почему бы просто не организовывать некую «буферную зону» вокруг важных ячеек, дабы их нельзя было подобным образом менять?
                  0
                  А какие ячейки назвать важными? Программа может получить от чипов памяти достаточную информацию чтобы выяснить её организацию и применить нужный алгоритм. Это конечно будет довольно сложно, но моделей чипов памяти ограниченное количество.
                  Самая простая защита от этой фигни — на материнке по разному разводить шины адреса и данных. А сами чипы производить со случайным распределением шин данных в каждой странице памяти. Это сильно снизит результативность атаки, и скорей будет приводить к повреждению соседних областей памяти что может приводить к многочисленным аппаратным ошибкам и не может остаться незамеченным.
                  Кстати дополнительным противодействующим фактором может выступить неизвестное программе распределение ячеек по каналам контроллера памяти когда модуля памяти может быть не один а два или три работающих в многоканальном режиме.
                    0
                    а сами чипы производить со случайным распределением шин данных в каждой странице памяти
                    Ого! А не разумней ли усилия направить на устранение бага в чипах, могущего доставлять неприятности помимо безопасности.
                      0
                      Судя по тому что баг не исправили — это чрезвычайно трудно и граничит с фундаментальной проблемой. Например, проблема обусловлена плотностью ячеек… и единственный способ её решить это снизить плотность ячеек, т.е. откатится в ёмкости чипа назад…
                      Конечно, подробностей мало озвучивают почему это происходит… было бы интересно узнать а пока остаётся только строить догадки.
                        0
                        Исправлять баг можно по разному.
                        У нанд флеша, например, тоже есть фундаментальные проблемы, однако контроллеры с ними успешно борются (хотя на низком уровне проблемы никуда не исчезают).
                        Чипы со случайным распределением шин на кристалле это security through obscurity, сама проблема при этом остается на месте. При этом производить фактически 100500 разных (пусть и в мелочах) кристаллов может оказаться удовольствием более дорогим, чем даже просто тупо зафигачивать больше битов под ECC.
                          0
                          Однако, это позволит снизить процент успешности атаки и повысить её стоимость. Что вобщем-то тоже было бы неплохо, как дополнительный эшелон в рамках общей системы защиты.
                    0
                    может не очень хорошо понял механизм уязвимости

                    Это разновидность глич-атаки (Differential Fault Analysis, DFA), первыми заявили в BellCore, затем Ади Шамир и Эли Бихам развили. если мне не изменяет память, Шамир нагреванием вскрывал то ли симки то ли чипы кредиток — при желании можно нагуглить.
                      –4
                      0100100100...

                      Почти угадали
                      image
                        +5
                        Тесты завершались успехом также в случае DDR3-чипов с защитой от Rowhammer под названием ECC (error-correction code).

                        чего-чего?
                          0
                          В принципе так и есть, если мы меняем посторонние биты в обход ECC то рано или поздно при считывании модифицированной ячейки с высокой вероятностью обнаружим ошибку чётности...

                        Only users with full accounts can post comments. Log in, please.