The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Разработан метод атаки на уязвимость в DRAM-памяти с использованием JavaScript

05.08.2015 12:31

Группа исследователей из Корнелльского университета (США) разработала технику проведения атаки с использованием уязвимости RowHammer в современных чипах памяти DRAM, примечательную необходимостью запуска только высокоуровневого кода на языке JavaScript. При помощи нового метода атака может быть проведена через размещение JavaScript-кода на любом сайте, без необходимости выполнения на стороне жертвы заданных машинных инструкций.

Так как из JavaScript-кода невозможно явно выполнить машинные инструкции CLFLUSH, для очистки процессорного кэша в представленной реализации используются косвенные методы вытеснения данных из кэша. По сравнению с предложенными ранее типовыми алгоритмами вытеснения из кэша эффективность нового метода значительно выше и может достигать 99.99%. Для обращения к фиксированным ячейкам памяти используется особенность браузеров выделять страницы памяти для больших типизированных массивов JavaScript.

В текущем прототипе эксплоита пока удалось добиться только повреждения памяти как таковой, без доведения атаки до получения прав root. Эксплоит был продемонстрирован на ноутбуке Lenovo x230 (Ivy Bridge) и был работоспособен только при увеличении в настройках интервала регенерации памяти, что иногда делается любителями компьютерных игр для увеличения производительности. С одной стороны для атаки требуются специфичные условия, но с другой стороны заставляет задуматься сам факт совершения атаки подобного уровня на JavaScript. Кроме того, опасность атаки усиливается возможностью её проведения извне, без получения прямого доступа к системе - размещение вредоносного JavaScript-кода на популярных ресурсах может привести к единовременному охвату очень большого числа пользователей.

Напомним, что атака RowHammer вызвана эффектом искажения содержимого отдельных битов памяти DRAM, повреждение которых может быть инициировано через цикличное чтение данных из соседних ячеек памяти (простой цикл с чтением содержимого памяти и очисткой кэша). Проблема обусловлена особенностью работы памяти DRAM, которая формируется как двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора. Состояние сохранённого в ячейке значения определяется тем, заряжен или нет конденсатор. Для поддержания заряда применяется цикл регенерации. При выполнении непрерывного чтения одной и той же области памяти из-за постоянного открытия и закрытия линии WL (Word Line), которая управляет транзисторами доступа, возникают флуктуации напряжения, которые могут привести к аномалии, вызывающей небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.

  1. Главная ссылка к новости (http://arstechnica.com/securit...)
  2. OpenNews: Продемонстрировано использование уязвимости в DRAM-памяти для повышения привилегий в системе
  3. OpenNews: Содержимое ячеек DRAM может быть повреждено в результате цикличного чтения
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/42730-dram
Ключевые слова: dram, javascript
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Crazy Alex (??), 12:51, 05/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Очередное подтверждпние - не стоит надеяться на песочницы, надо избегать самого недоверенного кода. Но ведь продолжат же тащить эти костыли под названием веб-приложения.
     
     
  • 2.2, Owlet (?), 12:57, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Конечно, ведь надо отказаться от компьютеров и уйти в пещеры. А то ужас какой, очередной эксплоит, который даже в лабораторных условиях не несёт особой пользы.
     
     
  • 3.9, Crazy Alex (ok), 13:19, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Достаточно пользоваться софтом из репозиториев, а не чем попало, что из сокета прилетело.
     
     
  • 4.11, slavius (?), 13:26, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • –11 +/
    достаточно отрубить java))) и спать спокойно)) или никому этого в голову не пришло? опять же проблему можно вызвать только на персоналках, поскольку на серваках браузерами не пользуются обычно)) не от вид деятельности))
     
     
  • 5.13, Crazy Alex (ok), 13:38, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну да. Только Javascript, а не Java (хотя тоже не помешает, конечно). Но это как частный костыль. А в общем - сама идея выполнения чего-то, что прилетело из сети без какого-либо контроля - порочна. Настолько, что по сравнению с ней даже MS и прочие подобные уроды кажутся лапочками - там хоть набор багов и троянов прилетает из понятного источника и поддаётся какому-никакому контролю (как минимум, понятно, кто виноват).
     
  • 5.21, Аноним (-), 14:39, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > достаточно отрубить java))) и спать спокойно)) или никому этого в голову не
    > пришло? опять же проблему можно вызвать только на персоналках, поскольку на
    > серваках браузерами не пользуются обычно)) не от вид деятельности))

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

     
     
  • 6.29, slavius (?), 16:36, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    так запретить java-script  к исполнению и все. опять же сработает только на рабочих станциях, т.к. на серваках обычно по сети не парсят)) принцип тот же. noscript не?))
     
     
  • 7.34, Аноним (-), 17:55, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >More general, the presented approach  can  be  applied  to  any  programming  language  and any  runtime  environment.

    У тебя трудности с чтением, или что?

     
  • 2.48, кукарача (?), 10:56, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это ещё одно подтверждение что интерактивность в современной вэб не нужна, рюшечки-перделочки, главное содержание
     
     
  • 3.51, Читама (?), 12:34, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Интерактивность нужна, но её можно добиться и правильными css. Только всякие css вызывающие подгрузку данных с других сайтов нужно убирать. Например, вместо прямой подгрузки недостающего шрифт можно встроить в браузер все популярные шрифты, а сайту знать какой шрифт есть - не нужно. Ну и т.д., всё решаемо, только w3c нужно менять.
     
     
  • 4.53, arisu (ok), 13:00, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    да чего там — сразу весь интернет в браузер встроить, да и все дела!
     

  • 1.4, А (??), 13:05, 05/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    у меня DDR2, мне бояться? :)))))
     
     
  • 2.6, Аноним (-), 13:10, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, только в DDR4 пофиксили.
     
  • 2.7, Аноним (-), 13:14, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Написано же: DRAM. Не боятся можно только пользователям EDO или FPM. Можно было бы пройти по ссылкам и почиать что там на самом деле, но я на 100% доверяю авторам новостей на opennet.
     
     
  • 3.14, Аноним (-), 13:48, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не боятся можно только пользователям EDO или FPM

    Не любители ходить по ссылкам в новости могут продолжать бояться :)
    https://www.opennet.ru/opennews/art.shtml?num=41340
    > Отмечается, что старые чипы DRAM, выпущенные до 2011 года, значительно более устойчивы к возникновению подобных ошибок. Из более ста протестированных новых модулей памяти, выпущенных в 2012 и 2013 годах, все без исключения оказались подвержены проблеме.

    И да, почему все взъелись на жабоскрипт (а некоторые клоуны -- на ядро пингвина) -- не ясно. Тут в первую очередь производителей железа пинать надо.

     
     
  • 4.16, Crazy Alex (ok), 14:01, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С клоунами как раз понятно - работа у них такая. В цирке.

    А с JS - потому что это не первая и наверняка не последняя проблема, которой в принципе нет, когда код не исполняется без аппрува админа (которым может быть и сам пользователь). Начиная с миллиона вариантв фингерпринтинга и заканчивая разными 0day. В этом плане Flash, java applets, Javascript - одного поля ягоды совершеннно.

     
     
  • 5.19, анон (?), 14:26, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А чем принципиально отличается код (которому нужен "аппрув админа") от данных? Скажем, любой документ с мало-мальски сложной структурой (но "данные") потенциально может вызвать некий паттерн доступов к оперативке со стороны кода, который читает этот документ, и использовать ту же уязвимость. Собственно говоря, Javascript и является таким документом, который выполняется виртуальной машиной, конечно, с JIT-компиляцией и т.д., но всё же достаточно далеко от нативного кода. К примеру, вдруг можно сделать видео, декодирование которого может вызывать такие эффекты. Так что, теперь надо писать код, который сам себя контролирует, когда обрабатывает данные, чтобы избегать всяких кривых паттернов? Может лучше железо всё же исправить?
     
     
  • 6.33, Crazy Alex (ok), 16:57, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Если коротко - то тем, что в коде создать вяскую дрянь намного проще. Код сам по себе даёт возможность предположить, как именно он будет выполняться - способов сделать это оптимально не так уж и много. И дрянь ни разу не ограничивается этим конкретным багом - вариантов много - DOS, фингерпринтинг, получение привилегий... да что угодно.
     
  • 5.28, arisu (ok), 16:35, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    да пофигу тут на js, как верно уважаемый аноним написал: тут в самой консерватории проблема, а не в том, что на трубе играют по‐всякому.
     
  • 4.25, А (??), 16:22, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, добрый человек :)

    мой нетбук с DDR-2 не сломать злодеям :)

    http://pastebin.com/AnYkW566

    ./a.out
    #0 ........................................ OK

    #32 ........................................ OK
    #33 .DRAM seems works fine...

     
     
  • 5.35, Аноним (-), 18:22, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Аналогично пофигично.
    Десктоп с DDR2-800.
     
  • 5.44, Аноним (-), 23:33, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ./a.out
    > #0 ........................................ OK
    > #32 ........................................ OK
    > #33 .DRAM seems works fine...

    Его для начала надо запусить надолго. Он далеко не всегда сразу вызывает видимые эффекты.

     
     
  • 6.46, max (??), 05:35, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> ./a.out
    >> #0 ........................................ OK
    >> #32 ........................................ OK
    >> #33 .DRAM seems works fine...
    > Его для начала надо запусить надолго. Он далеко не всегда сразу вызывает
    > видимые эффекты.

    уже более 3х часов крутится на DDR3‑1333 -- никаких видимых эффектов, только память потихоньку отжирает... подожду еще немного, может к границе 16G сглючит ))

     
  • 3.40, Аноним (-), 23:27, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Написано же: DRAM. Не боятся можно только пользователям EDO или FPM.

    Пользователи ECC - как минимум заметят проблему. А может и атака не состоится. И не все системы подвержены атаке. Но заблокировать JS не лишне.

     
  • 2.39, Anonplus (?), 21:50, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Успешность атаки зависит от скорости памяти. DDR2 не дотягивает, DDR3 уязвима и в её эпоху эту дырень и обнаружили, в DDR4 это исправили.

    Мне повезло, посижу на DDR2, подожду, пока эти ваши UEFI окончательно созреют и закроют в них основные дыры (период латания дыр начнется очень скоро, как только закончится период "давайте еще напихаем в UEFI OpenGL с поняшками"). Вот тогда сразу на DDR4 и пересяду.

     
     
  • 3.41, Аноним (-), 23:28, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Успешность атаки зависит от скорости памяти. DDR2 не дотягивает,

    Вот это весьма громкое утверждене. То-есть запросов конечно надо много и в одну область, но кто там куда дотягивает - а это кто-то проверял?


     
  • 3.55, max (??), 16:21, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    у меня на DDR3 так и не обнаружилось дыры (см выше)... видимо, вся эта история о DRAM-памяти -- маркетинговый фэйк
     

  • 1.15, Нанобот (ok), 14:00, 05/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >метод атаки на уязвимость в DRAM-памяти с использованием JavaScript

    до чего техника дошла!..

     
  • 1.17, Ydro (?), 14:21, 05/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    При должном подборе CSS-тэгов, используя нагруженную CSS-animation и правильно подобранные интервалы можно попробовать и без скриптов такое вытворить.
     
     
  • 2.52, Читама (?), 12:39, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > При должном подборе CSS-тэгов, используя нагруженную CSS-animation и правильно подобранные
    > интервалы можно попробовать и без скриптов такое вытворить.

    Но это думаю и пофиксить не сложно на стороне браузера.

     

  • 1.23, Аноним (-), 14:48, 05/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Правильно ли я понимаю, что проблема появляется из-за предсказуемости размещения переменных в физической памяти? Если сделать искусственную рандомизацию размещения, поможет ли это?
     
     
  • 2.61, pavlinux (ok), 01:07, 10/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Правильно ли я понимаю,

    Нет.

     

  • 1.26, arisu (ok), 16:32, 05/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    любо!

    жду атаки при помощи просто загрузки хитрого html и css.

     
     
  • 2.38, IZh. (?), 21:40, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В конкретном браузере конкретной версии вполне можно какое-нибудь переполнение буфера вызвать. Не уж-то браузер никогда не падал? Вот, вам, и эксплоит на HTML + CSS.
     
  • 2.42, Аноним (-), 23:30, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > жду атаки при помощи просто загрузки хитрого html и css.

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


     
     
  • 3.45, Аноним (-), 00:02, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Помнишь сказ про то что настоящие профессионалы используют бабочек,

    Почему сразу "сказ"?
    В оси Emacs/Linux (см. соседнюю новость https://www.opennet.ru/opennews/art.shtml?num=42726 )
    делается простейшим:
    M-x butterfly

     
  • 2.56, Vkni (ok), 09:21, 08/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > любо!

    Простите, а Люба - это кто?

     
     
  • 3.57, arisu (ok), 12:20, 08/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    это идиотский вопрос, показывающий твоё плохое знание русского.

    как‐то так.

     
     
  • 4.59, Vkni (ok), 06:48, 09/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Это цЫтата. :-)

     
     
  • 5.60, arisu (ok), 13:42, 09/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Это цЫтата. :-)

    это глупая цитата в глупом месте.

     

  • 1.36, Аноним (-), 18:36, 05/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "при увеличении в настройках интервала регенерации памяти, что иногда делается любителями компьютерных игр для увеличения производительности."

    Кто-нибудь в курсе этого мега-разгона?

    (
    Нашёл

    Регенерация памяти, к сожалению, отнимает время у процессора. Каждый цикл регенерации по длительности занимает несколько тактов центрального процессора. В старых компьютерах циклы регенерации могли занимать до 10% (или больше) процессорного времени, но в современных системах эти расходы составляют менее 1%.
    )

     
     
  • 2.43, Аноним (-), 23:31, 05/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    У современной памяти есть self-refresh, он без участия проца случается.
     
     
  • 3.47, Cameron (?), 10:06, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Но память в этот момент всё равно недоступна. Поэтому для синтетических тестов увеличение периода регенирации даёт определённый прирост. Но  на реальных приложениях после появления двухканального режима работы, практически никак не сказывается.
     

  • 1.49, xaxaxa (?), 11:09, 06/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ddr1, много смеюсь от последних новостей
     
     
  • 2.50, Аноним (-), 11:52, 06/08/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    simm, наконец-то загрузилась эта страница
     
     
  • 3.58, count0krsk (ok), 19:26, 08/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    С брелка снял, признавайся? Или к принтеру монитор припаял? )))
     

  • 1.54, z (??), 13:27, 06/08/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Один из вариантов усложнения атаки - отключение HugePages
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру