Группа исследователей из амстердамского свободного университета разработала (https://www.vusec.net/projects/anc/) (pdf 1 (http://www.cs.vu.nl/~herbertb/download/papers/revanc_ir-cs-7... pdf 2 (http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf)) новую технику обхода механизма защиты ASLR (Address space layout randomization), позволяющую определить раскладку памяти процесса. Особенностью предложенного метода является то, что он может быть реализован на языке JavaScript, что значительно упрощает обход дополнительных уровней защиты при эксплуатации уязвимостей в web-браузерах.
По заявлению исследователей предложенный метод универсален и надёжно работает в Chrome и Firefox как минимум на 22 микроархитектурах, включая процессоры Intel Xeon, Atom, Core, Celeron (CVE-2017-5925), AMD (CVE-2017-5926), Allwinner, Samsung Exynos, NVIDIA Tegra (CVE-2017-5927 для ARM) и др. Если в обычных условиях для успешной эксплуатации новой уязвимости в Firefox требуется наличие ещё одной уязвимости, которая позволит получить сведения о ASLR-смещениях в адресном пространстве процесса, то предложенная техника позволяет выявить эти смещения путём выполнения скрипта на языке JavaScript.
Метод является разновидностью атак по сторонним каналам (side-channel attacks) и основан на косвенном определении адресов к которым ранее были обращения при обходе таблиц страниц памяти процессорным блоком MMU (https://ru.wikipedia.org/wiki/%D0%91%D0%... (Memory Management Unit) в ходе трансляции адресов виртуальной памяти в адреса физической памяти. Так как кэш CPU общий и в нём отражается как активность приложения и так и активность блока MMU, то путём оценки различий во времени доступа к данным до и после сброса кэша (разновидность атаки "EVICT+TIME") можно с высокой вероятностью подобрать адрес, по которому было обращение.
Проблема усугубляется тем, что атака основывается на аппаратных особенностях кэширования адресов в современных процессорах и с ней трудно бороться на программном уровне без отключения кэша или без выполнения манипуляций, заметно снижающих производительность. Реализация защиты на аппаратном уровне также затруднена, так как требует создания отдельного кэша для таблиц страниц памяти.
URL: https://arstechnica.com/security/2017/02/new-aslr-busting-ja.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=46062
И чем это грозит?
https://ru.wikipedia.org/wiki/ASLR
Грозит большими проблемами с безопасностью из-за качества кода. Если рандомизации адресов не будет, открывается отлдскульный полигон для не менее олдскульных эксплоитов.
Если нет дыр - ничем
>нет дыр
>делает вид, что программистЯсно.
Вот как раз программисту понятно, что если в системе создавать дыры вроде браузера с исполняемым без спросу непонятно каким кодом - то ASLR не поможет. И песочницы не помогут. Сложность уж больно большая.Если же вести себя вменяемо - ставить код из доверенных источников, обновляться и вообще включать голову - то ASLR нужно примерно так же, как selinux какой-нибудь - то есть если нет требований повышенной безопасности - на фиг не нужно.
Дает возможность использовать другие дыры
Ну дела
я же говорил яваскрипт не нужен вспомнити npm left pad. А еще вспомнити 0.1 + 0.2 = .300000000000004 а еще вспомнити Nan =! Nan
> А еще вспомнити 0.1 + 0.2 = .300000000000004Так и запишем, что анон не в курсе про IEEE 754
> Nan =! NanЕще про этот пункт забыли упомянуть в тот-же стандарт.
Тебе ещё не надоело в каждую тему про JS отписываться? Слишком толсто
Ну ещё про грамматику нужно вспонить.
Вспонить от слова пони?
> вспомнитиТы должен мне новые глаза.
JS добрался и до кэша процессора? Мир перевернулся.
> увеличить уровень энтропии ASLR с 24-28 бит до 35 битЧем это поможет? Только время увеличить и задержки.
Вот интерсно - на кой JS вообще доступ к высокоточному таймру?
> Вот интерсно - на кой JS вообще доступ к высокоточному таймру?time.ru?
для игорей. Ну и node.js хочет сто пудов
хм, судя по стековерфлоу в js (во всяком случае, в браузерах) таймер миллисекундный, и то точность не ахти. удивительно, что его хватает.
Для игорей просто просится requestAnimationFrame
Получается, что любой браузер (и не только) потенциально уязвим и проблема лежит в самом принципе работы процессора и ОЗУ.
Выходит даже пресловутый Servo не сможет помочь в сложившейся ситуации.
У пресловутого серво, внезапно, тот же жаваскрипт движок что в лисе.
> Получается, что любой браузер (и не только) потенциально уязвим и проблема лежит
> в самом принципе работы процессора и ОЗУ.
> Выходит даже пресловутый Servo не сможет помочь в сложившейся ситуации.Нет.
Получается в данном случае только то, что дырявый браузер остаётся дырой не смотря на ASLR. То есть ASLR как метод закрытия дыр (в дырявом ПО) не вполне удовлетворительно. Что впрочем и так заметно...
Мне кажется это логичным. Если в коде самого браузера есть дыры, то тут ничего не поможет.
Я думаю, что в таком случае нужна изоляция памяти процессов на аппаратном уровне. Т.е когда процесс в принципе не может обратиться к памяти, которая ему не принадлежит. Но в таком случае встанет проблема наличия разделяемой памяти. Выходит замкнутый круг.
Поэтому надо писать код браузеров/JS движков правильно.
Еадо минимизировать выполнение стороннего кода без запроса. Гонять данные, а программ устанавливать явно, из доверенных источников. Тогда ASLR будет на месте (если уж вообще его хочется) - как оборона от случайных уязвимостей в локальном коде, когда ему передают специфически созданные данные.А идея "мы создадим песочницу и будем там выполнять всё, что из сети прилетело" совершенно безумна. Что и демонстрируют каждый раз очередные дыры.
Продолжая мысль rust ненужен, js - среда исполнения эксплойтов
Новость не читай, сразу комментируй!>> На GitHub размещена эталонная реализация метода на языке Си.
Вот только Сишный код надо как-то предварительно доставить на компьютер пользователя, а JS загружается фоном автоматически при просмотре картинок с котятками в интернетах.
А толку? Без актуальной уязвимости, находясь в песочнице браузера, данные из памяти не прочтешь. Читай текст новости внимательней - на JS только техника обхода ASLR и все.
Ну это, в общем, и так не первый год понятно - достаточно только посмотреть на то количество дыр, которое обнаруживалось в браузерах, и сравнить с количеством дыр в любом другом сравнимом по масштабам сетевом софте.
Когда-то Крис Касперски смог хакнуть интеловский процессор кодом на жабоскрипте. История повторяется.
там, вроде, тёмная история - то ли смог, то ли сбрехал...
SELinux,
ASLR,Скрытые АНБ разработки радует глаз.
"Взлом через кэш процессора на JavaScript через браузер! Скоро форт Нокс ломанут пластмассовым совочком и игрушечным экскаватором из песочницы в Москве." (с) хабра.
Коммент к видео:It is sad that every so many so-called "researchers" need to portray their findings as a doomsday scenario ASLR does not protect against drive-by exploits. It's purpose is to provide an additional layer of defense against buffer-overflow exploits by removing the predictability of adjacent blocks of memory. All this JS PoC does is negate that layer. It is not an exploit itself, nor does it even facilitate an exploit. For this really to mean anything: • An actual exploitable buffer-overflow vulnerability must be known. With modern technology combined with modern awareness these are relatively rare, though they are possible. • An exploit via javascript must be available and deliverable. This limits the scope of vulnerable applications. • That javascript would need to incorporate this PoC The target audience for such an exploit would be desktop/mobile, where a browser is used. Servers would not be in scope. This would also be limited to the user context running the browser (does anyone really still run a browser with full administrative privileges?) Is this finding significant? Definitely yes. Does it mean ASLR is "insecure" (as quoted by the so-called "researchers")? Absolutely not.
топ кек, никому и не нужны full administrative права доступа. Всего то украдут ваши пароли.
Все более актуальным становится отключение js по дефолту.
(с включением на доверенных сайтах)
А толку? Я смотрю, никто в текст новости не вчитывается...
Ребята суть не в JS, и даже не в C, суть в голимости ASLR
> Ребята суть не в JS, и даже не в C, суть в
> голимости ASLRНе, ребята в памперсы суть.