Запись обращений к кэшу устройством управления памятью (MMU) в процессоре по мере вызова страниц по особому паттерну, разработанному для выявления различий между разными уровнями иерархии таблиц. Например, паттерн «лесенки» (слева) указывает на первый уровень иерархии, то есть PTL1, при вызове страниц по 32K. Для других уровней иерархии тоже есть методы выявления

Пятеро исследователей из Амстердамского свободного университета (Нидерланды) доказали фундаментальную уязвимость техники защиты памяти ASLR на современных процессорах. Они выложили исходный код и подробное описание атаки AnC (ASLR?Cache), которой подвержены практически все процессоры.

Исследователи проверили AnC на 22 процессорах разных архитектур — и не нашли ни одного, который был бы защищён от такого рода атаки по стороннему каналу. Это и понятно, ведь во всех процессорах используется буфер динамической трансляции для кэширования адресов памяти, которые транслируются в виртуальные адреса. Защититься от этой атаки можно только отключив кэш процессора.

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

В прошлом исследователи несколько раз показывали, что защиту ASLR можно обойти в некоторых случаях. Например, если у злоумышленника есть полные права в системе, он может сломать ASLR на уровне ядра ОС. Но в типичных условиях — против атаки через браузер — ASLR считалась вполне надёжной защитой. Теперь нет.

В 2016 году эта же группа голландских специалистов показала, как с помощью JavaScript обойти защиту ASLR в браузере Microsoft Edge, используя атаку по стороннему каналу дедупликации памяти. Microsoft быстро отключила дедубликацию памяти, чтобы защитить своих пользователей. Но это не решило проблему ASLR на фундаментальном уровне, связанную с работой самого устройства управления памятью (MMU) в процессорах.

В современных процессорах модуль MMU использует иерархию кэша для улучшения производительности прохода по иерархическим таблицам страниц в памяти. Это неотъемлемая функция современных процессоров. Корень проблемы в том, что кэш L3 доступен для любых сторонних приложений, в том числе скриптов JavaScript из браузера.


Организация памяти в современном процессоре Intel

Хакеры сумели определить средствами JavaScript, к каким страницам в таблицах страниц чаще всего обращается модуль MMU. Точность определения вполне достаточна для обхода ASLR даже с энтропией 36 бит.

Принцип атаки


Принцип атаки ASLR?Cache основан на том, что в результате прохода MMU по таблицам страниц происходит их запись в кэш процессора. Эта операция осуществляется и во время трансляции виртуального адреса в соответствующий ему физический адрес в памяти. Таким образом, буфер динамической трансляции (TLB) в каждом процессоре всегда хранит самые последние трансляции адресов.

Если происходит промах мимо кэша TLB, то модулю MMU придётся пройти по всем таблицам страниц конкретного процесса (тоже хранящимся в основной памяти), чтобы выполнить трансляцию. Для улучшения производительности MMU в такой ситуации таблицы страниц кэшируются в быстром кэше процессора L3 для ускорения доступа к ним.

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


Проход MMU по таблице страниц для трансляции адреса 0x644b321f4000 в соответствующую страницу памяти на архитектуре x86_64

Хакеры разработали специальную технику сканирования памяти (им нужны были таймеры получше, чем есть в браузерах), чтобы определить наборы кэша (конкретные строки в секторированном кэше прямого отображения), к которым обращается MMU после таргетированного прохода по таблицам страниц, когда происходит разыменование указателя данных или исполнение инструкции кода. Поскольку только определённые адреса могут соответствовать определённым наборам кэша, то получение информации об этих наборах выдаёт начальные номера записей нужных записей таблиц страниц на каждом уровне иерархии — и, таким образом, дерандомизирует ASLR.

Исследователи протестировали эксплойт в Chrome и Firefox на 22-ти современных процессорах и показали его успешную работу.


Успешность атаки в Chrome и Firefox и процент ложных срабатываний

Не спасают даже встроенные механизмы защиты вроде умышленной поломки разработчиками браузеров точного JavaScript-таймера performance.now().


Сломанный таймер performance.now() в Chrome и Firefox

Авторы эксплойта написали собственный таймер.

Демонстрация атаки в Firefox

Атака проверена на следующих процессорах:

Модель процессора Микроархитектура Год
Intel Xeon E3-1240 v5 Skylake 2015
Intel Core i7-6700K Skylake 2015
Intel Celeron N2840 Silvermont 2014
Intel Xeon E5-2658 v2 Ivy Bridge EP 2013
Intel Atom C2750 Silvermont 2013
Intel Core i7-4500U Haswell 2013
Intel Core i7-3632QM Ivy Bridge 2012
Intel Core i7-2620QM Sandy Bridge 2011
Intel Core i5 M480 Westmere 2010
Intel Core i7 920 Nehalem 2008
AMD FX-8350 8-Core Piledriver 2012
AMD FX-8320 8-Core Piledriver 2012
AMD FX-8120 8-Core Bulldozer 2011
AMD Athlon II 640 X4 K10 2010
AMD E-350 Bobcat 2010
AMD Phenom 9550 4-Core K10 2008
Allwinner A64 ARM Cortex A53 2016
Samsung Exynos 5800 ARM Cortex A15 2014
Samsung Exynos 5800 ARM Cortex A7 2014
Nvidia Tegra K1 CD580M-A1 ARM Cortex A15 2014
Nvidia Tegra K1 CD570M-A1 ARM Cortex A15; LPAE  2014
К сожалению, описание этой техники в открытом доступе может снова сделать эффективными старые способы атаки на кэш, от которых вроде бы уже давно защитились.

В данный момент атака AnC задокументирована в четырёх бюллетенях безопасности:

  • CVE-2017-5925 — для процессоров Intel;
  • CVE-2017-5926 — для процессоров AMD;
  • CVE-2017-5927 — для процессоров ARM;
  • CVE-2017-5928 — для JavaScript-тайеров в разных браузерах.

По мнению авторов, единственным способом защиты для пользователя является использование программ вроде NoScript, которые блокирует выполнение сторонних скриптов JavaScript в браузере.
Поделиться с друзьями
-->

Комментарии (18)


  1. cranium256
    16.02.2017 21:00
    +13

    Взлом через кэш процессора на JavaScript через браузер! Скоро форт Нокс ломанут пластмассовым совочком и игрушечным экскаватором из песочницы в Москве.


  1. MacIn
    16.02.2017 22:34
    +2

    По мнению авторов, единственным способом защиты для пользователя является использование программ вроде NoScript, которые блокирует выполнение сторонних скриптов JavaScript в браузере.

    Как определяется набор «белых» скриптов для подобных инструментов? При полном отключении JS сейчас практически ни один сайт не работает, а множество «хороших» нужных для сайта скриптов тянутся с доменов с невнятными именами.


    1. pda0
      17.02.2017 00:41
      +4

      Боюсь, что никак. Создав JavaScript Netscape фактически позволила кому угодно выполнять произвольный код с правами пользователя. Тогда это не казалось опасным, потому что он был тормозным и ничего не мог. Теперь от него хотят rich-приложений, кодеков видео и т.д.

      Похоже flash был решетом не потому что его писали криворучки, а потому что был крайне соблазнительным каналом запуска произвольного кода. Теперь его место прочно занял JavaScript.

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


      1. qw1
        18.02.2017 11:24

        Создав JavaScript Netscape фактически позволила кому угодно выполнять произвольный код с правами пользователя
        Этим вы заявляете, что в каждой реализации js-интерпретатора есть существенные ошибки, типа переполнения буфера, или вызова методов объекта, который раньше был удалён.
        Придётся убить производительность JavaScript, заставив его работать с постоянной скоростью, не быстрее худшего случая
        Такие меры против лишь одного вектора атаки (дерандомизации ASLR), который сам по себе безобидный? Проще вообще отказаться от ASLR, тем более, что он уменьшает производительность OS и всех приложений.


        1. pda0
          18.02.2017 17:14

          тим вы заявляете, что в каждой реализации js-интерпретатора есть существенные ошибки

          Нет, хотя эмпирически это так. Я заявляю, что JavaScript в браузерах предоставляет возможность запуска произвольного кода из любых, посещённых пользователем источников, без ведома и позволения пользователя. И не важно, что он выполняется в песочнице виртуальной машины. Это всё равно выполняемый код. Это всё равно несравненно привлекательнее, чем искать уязвимости в библиотеках обработки изображений, например. Такая уязвимость не позволить эксплуатировать её с ASLR, но в сочетании с JavaScript — очень даже.

          Проще вообще отказаться от ASLR

          Зачем, когда от одиночных уязвимостей, не позволяющих выполнить сложный код он спасает?


          1. qw1
            18.02.2017 17:31

            Тогда нужно убрать замечание «с правами пользователя».
            Потому что с правами пользователя — это возможность создать файл на рабочем столе, или отправить письмо с почтового аккаунта. Что невозможно без выхода из песочницы браузера.


            1. pda0
              18.02.2017 23:55

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


  1. beeruser
    17.02.2017 00:30
    +14

    >> Они выложили исходники скриптов JavaScript

    Не обнаружив по ссылке ни одного JS файла, решил посмотреть оригинал статьи:

    We are not going to release the JavaScript version of AnC in order to protect Internet users from the AnC attack


  1. MrGobus
    17.02.2017 08:45
    +2

    В статье постоянно всплывает некий таймер, взломанный, измененный и т.п. Как понимать фразу «Авторы эксплойта написали собственный таймер.»? Как именно они это сделали? Зачем? И самое главное, они внесли изменения в код браузера?


    1. gekt0r
      17.02.2017 10:27

      Могу предположить, что они взяли какую-то атомарную операцию за единицу времени, и относительно этой операции считают. это только предположение


  1. ruzhovt
    17.02.2017 10:23
    +2

    JavaScript-ом в обход ASLR была взломана и PS Vita.

    https://henkaku.xyz/source/


  1. NeZnaika3
    17.02.2017 11:08

    Тест не был заказан производителями IE+Safari?
    Просто интересно, если почему исследовали лишь два браузера из всех используемых.
    Например, midori 0.5.11, не говоря про неизмеримое количество на зеленом роботе.


  1. uelkfr
    17.02.2017 11:10
    +2

    Не совсем понял, ну найдут они значения таблицы ASLR, но как по этим смещениям записать машинный код?


    1. sleeply4cat
      17.02.2017 11:21
      +4

      только комбинируя с каким-то реальным эксплойтом.


    1. MacIn
      17.02.2017 17:14

      Проблема-то не в «записать по этим смещениям», а «записать эти смещения куда-то, чтобы вызвать какую-то функцию».


  1. 60-fps
    17.02.2017 21:07

    Такое ощущение, что, производители ЦП, специально оставили лазейку, для своих целей…
    Да и сколько там уязвимостей наверное ни кто и не знает, для каждой службы свое окошко )


    1. qw1
      18.02.2017 11:17

      Когда проектировались таблицы трансляций, ASLR и в планах не было.


  1. dmitry_galinsky
    26.02.2017 12:45

    Проблема в записи этих смещений