Группа исследователей из Корнелльского университета (США) разработала (http://arxiv.org/abs/1507.06955) технику проведения атаки с использованием уязвимости RowHammer (http://www.opennet.me/opennews/art.shtml?num=41340) в современных чипах памяти DRAM, примечательную необходимостью запуска только высокоуровневого кода на языке JavaScript. При помощи нового метода атака может быть проведена через размещение JavaScript-кода на любом сайте, без необходимости выполнения на стороне жертвы машинных инструкций CLFLUSH.
Так как из JavaScript-кода невозможно явно выполнить специальные машинные инструкции, для очистки процессорного кэша в представленной реализации используются косвенные методы вытеснения данных из кэша. По сравнению с предложенными ранее типовыми алгоритмами вытеснения из кэша эффективность нового метода значительно выше и может достигать 99.99%.Ограничением разработанного прототипа эксплоита является невозможность доведения атаки до получения прав root, так как содержимое ячеек памяти изменяется непредсказуемым образом. При этом, с другой стороны, опасность атаки усиливается возможностью её проведения извне, без получения прямого доступа к системе - размещение вредоносного JavaScript-кода на популярных ресурсах может привести к единовременному охвату очень большого числа пользователей.
Напомним, что атака RowHammer вызвана эффектом искажения содержимого отдельных битов памяти DRAM, повреждение которых может быть инициировано через цикличное чтение данных из соседних ячеек памяти (простой цикл с чтением содержимого памяти и очисткой кэша). Проблема обусловлена особенностью работы памяти DRAM, которая формируется как двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора. Состояние сохранённого в ячейке значения определяется тем, заряжен или нет конденсатор. Для поддержания заряда применяется цикл регенерации. При выполнении непрерывного чтения одной и той же области памяти из-за постоянного открытия и закрытия линии WL (Word Line), которая управляет транзисторами доступа, возникают флуктуации напряжения, которые могут привести к аномалии, вызывающей небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.
URL: http://arstechnica.com/security/2015/08/dram-bitflipping-exp.../
Новость: http://www.opennet.me/opennews/art.shtml?num=42730
Очередное подтверждпние - не стоит надеяться на песочницы, надо избегать самого недоверенного кода. Но ведь продолжат же тащить эти костыли под названием веб-приложения.
Конечно, ведь надо отказаться от компьютеров и уйти в пещеры. А то ужас какой, очередной эксплоит, который даже в лабораторных условиях не несёт особой пользы.
Достаточно пользоваться софтом из репозиториев, а не чем попало, что из сокета прилетело.
достаточно отрубить java))) и спать спокойно)) или никому этого в голову не пришло? опять же проблему можно вызвать только на персоналках, поскольку на серваках браузерами не пользуются обычно)) не от вид деятельности))
Ну да. Только Javascript, а не Java (хотя тоже не помешает, конечно). Но это как частный костыль. А в общем - сама идея выполнения чего-то, что прилетело из сети без какого-либо контроля - порочна. Настолько, что по сравнению с ней даже MS и прочие подобные уроды кажутся лапочками - там хоть набор багов и троянов прилетает из понятного источника и поддаётся какому-никакому контролю (как минимум, понятно, кто виноват).
> достаточно отрубить java))) и спать спокойно)) или никому этого в голову не
> пришло? опять же проблему можно вызвать только на персоналках, поскольку на
> серваках браузерами не пользуются обычно)) не от вид деятельности))Тебе бы вот пришло в голову сперва прочитать оригинальную статью перед газификацией луж на форуме. Представленный способ не завязан на джаваскрипте (который к джаве не имеет никакого отношения, как уже заметили).
так запретить java-script к исполнению и все. опять же сработает только на рабочих станциях, т.к. на серваках обычно по сети не парсят)) принцип тот же. noscript не?))
>More general, the presented approach can be applied to any programming language and any runtime environment.У тебя трудности с чтением, или что?
Это ещё одно подтверждение что интерактивность в современной вэб не нужна, рюшечки-перделочки, главное содержание
Интерактивность нужна, но её можно добиться и правильными css. Только всякие css вызывающие подгрузку данных с других сайтов нужно убирать. Например, вместо прямой подгрузки недостающего шрифт можно встроить в браузер все популярные шрифты, а сайту знать какой шрифт есть - не нужно. Ну и т.д., всё решаемо, только w3c нужно менять.
да чего там — сразу весь интернет в браузер встроить, да и все дела!
у меня DDR2, мне бояться? :)))))
Да, только в DDR4 пофиксили.
Написано же: DRAM. Не боятся можно только пользователям EDO или FPM. Можно было бы пройти по ссылкам и почиать что там на самом деле, но я на 100% доверяю авторам новостей на opennet.
> Не боятся можно только пользователям EDO или FPMНе любители ходить по ссылкам в новости могут продолжать бояться :)
http://www.opennet.me/opennews/art.shtml?num=41340
> Отмечается, что старые чипы DRAM, выпущенные до 2011 года, значительно более устойчивы к возникновению подобных ошибок. Из более ста протестированных новых модулей памяти, выпущенных в 2012 и 2013 годах, все без исключения оказались подвержены проблеме.И да, почему все взъелись на жабоскрипт (а некоторые клоуны -- на ядро пингвина) -- не ясно. Тут в первую очередь производителей железа пинать надо.
С клоунами как раз понятно - работа у них такая. В цирке.А с JS - потому что это не первая и наверняка не последняя проблема, которой в принципе нет, когда код не исполняется без аппрува админа (которым может быть и сам пользователь). Начиная с миллиона вариантв фингерпринтинга и заканчивая разными 0day. В этом плане Flash, java applets, Javascript - одного поля ягоды совершеннно.
А чем принципиально отличается код (которому нужен "аппрув админа") от данных? Скажем, любой документ с мало-мальски сложной структурой (но "данные") потенциально может вызвать некий паттерн доступов к оперативке со стороны кода, который читает этот документ, и использовать ту же уязвимость. Собственно говоря, Javascript и является таким документом, который выполняется виртуальной машиной, конечно, с JIT-компиляцией и т.д., но всё же достаточно далеко от нативного кода. К примеру, вдруг можно сделать видео, декодирование которого может вызывать такие эффекты. Так что, теперь надо писать код, который сам себя контролирует, когда обрабатывает данные, чтобы избегать всяких кривых паттернов? Может лучше железо всё же исправить?
Если коротко - то тем, что в коде создать вяскую дрянь намного проще. Код сам по себе даёт возможность предположить, как именно он будет выполняться - способов сделать это оптимально не так уж и много. И дрянь ни разу не ограничивается этим конкретным багом - вариантов много - DOS, фингерпринтинг, получение привилегий... да что угодно.
да пофигу тут на js, как верно уважаемый аноним написал: тут в самой консерватории проблема, а не в том, что на трубе играют по‐всякому.
Спасибо, добрый человек :)мой нетбук с DDR-2 не сломать злодеям :)
./a.out
#0 ........................................ OK#32 ........................................ OK
#33 .DRAM seems works fine...
Аналогично пофигично.
Десктоп с DDR2-800.
> ./a.out
> #0 ........................................ OK
> #32 ........................................ OK
> #33 .DRAM seems works fine...Его для начала надо запусить надолго. Он далеко не всегда сразу вызывает видимые эффекты.
>> ./a.out
>> #0 ........................................ OK
>> #32 ........................................ OK
>> #33 .DRAM seems works fine...
> Его для начала надо запусить надолго. Он далеко не всегда сразу вызывает
> видимые эффекты.уже более 3х часов крутится на DDR3‑1333 -- никаких видимых эффектов, только память потихоньку отжирает... подожду еще немного, может к границе 16G сглючит ))
> Написано же: DRAM. Не боятся можно только пользователям EDO или FPM.Пользователи ECC - как минимум заметят проблему. А может и атака не состоится. И не все системы подвержены атаке. Но заблокировать JS не лишне.
Успешность атаки зависит от скорости памяти. DDR2 не дотягивает, DDR3 уязвима и в её эпоху эту дырень и обнаружили, в DDR4 это исправили.Мне повезло, посижу на DDR2, подожду, пока эти ваши UEFI окончательно созреют и закроют в них основные дыры (период латания дыр начнется очень скоро, как только закончится период "давайте еще напихаем в UEFI OpenGL с поняшками"). Вот тогда сразу на DDR4 и пересяду.
> Успешность атаки зависит от скорости памяти. DDR2 не дотягивает,Вот это весьма громкое утверждене. То-есть запросов конечно надо много и в одну область, но кто там куда дотягивает - а это кто-то проверял?
у меня на DDR3 так и не обнаружилось дыры (см выше)... видимо, вся эта история о DRAM-памяти -- маркетинговый фэйк
>метод атаки на уязвимость в DRAM-памяти с использованием JavaScriptдо чего техника дошла!..
При должном подборе CSS-тэгов, используя нагруженную CSS-animation и правильно подобранные интервалы можно попробовать и без скриптов такое вытворить.
> При должном подборе CSS-тэгов, используя нагруженную CSS-animation и правильно подобранные
> интервалы можно попробовать и без скриптов такое вытворить.Но это думаю и пофиксить не сложно на стороне браузера.
Правильно ли я понимаю, что проблема появляется из-за предсказуемости размещения переменных в физической памяти? Если сделать искусственную рандомизацию размещения, поможет ли это?
> Правильно ли я понимаю,Нет.
любо!жду атаки при помощи просто загрузки хитрого html и css.
В конкретном браузере конкретной версии вполне можно какое-нибудь переполнение буфера вызвать. Не уж-то браузер никогда не падал? Вот, вам, и эксплоит на HTML + CSS.
> жду атаки при помощи просто загрузки хитрого html и css.Помнишь сказ про то что настоящие профессионалы используют бабочек, вызывающих возмущение магнитного поля? С учетом сложности браузера наверное можно попробовать спровоцировать его на какой-нибудь дурной паттерн доступа к памяти косвенными методами, так что сказ про бабочек не настолько уж и... :)
> Помнишь сказ про то что настоящие профессионалы используют бабочек,Почему сразу "сказ"?
В оси Emacs/Linux (см. соседнюю новость http://www.opennet.me/opennews/art.shtml?num=42726 )
делается простейшим:
M-x butterfly
> любо!Простите, а Люба - это кто?
это идиотский вопрос, показывающий твоё плохое знание русского.как‐то так.
Это цЫтата. :-)
> Это цЫтата. :-)это глупая цитата в глупом месте.
"при увеличении в настройках интервала регенерации памяти, что иногда делается любителями компьютерных игр для увеличения производительности."Кто-нибудь в курсе этого мега-разгона?
(
НашёлРегенерация памяти, к сожалению, отнимает время у процессора. Каждый цикл регенерации по длительности занимает несколько тактов центрального процессора. В старых компьютерах циклы регенерации могли занимать до 10% (или больше) процессорного времени, но в современных системах эти расходы составляют менее 1%.
)
У современной памяти есть self-refresh, он без участия проца случается.
Но память в этот момент всё равно недоступна. Поэтому для синтетических тестов увеличение периода регенирации даёт определённый прирост. Но на реальных приложениях после появления двухканального режима работы, практически никак не сказывается.
ddr1, много смеюсь от последних новостей
simm, наконец-то загрузилась эта страница
С брелка снял, признавайся? Или к принтеру монитор припаял? )))
Один из вариантов усложнения атаки - отключение HugePages