The OpenNET Project / Index page

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

Атака NetSpectre, приводящая к утечке содержимого памяти по сети

27.07.2018 09:00

Группа исследователей из Грацского технического университета (Австрия), ранее известная разработкой метода эксплуатация уязвимости в DRAM-памяти через локальную сеть, опубликовала описание новой атаки NetSpectre, позволяющей инициировать утечку данных из памяти через манипуляцию с сетевыми пакетами, отправляемыми по сети.

Опасность атаки сглаживается её низкой производительностью - в оптимальных условиях предложенный метод позволяет определить 15-60 бит данных в час или 45-180 байт в день. В реальных условиях скорость значительно ниже, например, тестовая атака на окружение в Google Cloud позволила извлечь лишь 1-3 байт за 3-8 часов атаки (потребовалось выполнить около 20 млн проверок для определения одного бита). Ожидается, что со временем будут предложены методы, повышающие эффективность атаки, но в любом случае на извлечение ключа AES потребуются дни. По заявлению компании Intel атака блокируется методами защиты, предложенными для первого варианта уязвимости Spectre (CVE-2017-5753).

Метод атаки основывается на нахождении в типовых программах и ядре фрагментов кода (гаджетов), приводящих к спекулятивному обращению к областям памяти ("leak gadget") и раскрытию информации по сети ("transmit gadget"). Например, во многих приложениях встречаются конструкции вида (важно само обращение к bitstream[x] после проверки границ):


   if (x < bitstream_length)
      if(bitstream[x])
         flag = true;

Если подобные фрагменты применяются при обработке сетевых пакетов и атакующий может сформировать запрос, в котором значение "x" выходит за пределы допустимых значений, то появляется возможность инициирования спекулятивного обращения к областям памяти вне допустимых границ. Результат данных спекулятивных операций отбрасывается процессором, но оседает в кэше и доступен для извлечения при помощи методов анализа содержимого кэша по сторонним каналам. Для успешного спекулятивного выполнения перед передачей выходящего за границы значения "x" требуется предварительно натренировать блок предсказания переходов корректными значениями, в этом случае сработает оптимизация по спекулятивному обращению к памяти до того как станет известен результат проверки условного оператора.

Для определения остаточных данных также предлагается использовать существующие фрагменты кода в приложениях или ядре ("transmit gadget"), которые активируются при поступлении определённых видов сетевых запросов. Например, для извлечения осевших в кэше данных исследователями предложена модификация метода Evict+Reload, основанного на создании условий для вытеснения данных из кэша (например, создаётся сетевая активность равномерно заполняющая кэш типовым содержимым) и обработки запросов, время выполнения которых позволяет судить о наличии данных в процессорном кэше. Скорость проведения подобной атаки по сети не превышает 15 бит в час.

Для повышения производительности до 60 бит в час исследователи предложили использовать гаджеты с инструкциями AVX2 в качестве дополнительного канала утечки информации. Метод основан на особенностях перевода блока AVX2 в режим энергосбережения. В случае неактивного использования AVX2 предусмотрен режим экономии энергии, при котором блок AVX2 продолжает работать, но снижается его производительность. В случае неактивности AVX2 в течение 1 мс процессор полностью отключает блок AVX2, что приводит к появлению заметной задержки при выполнении следующей операции.

При использовании инструкций AVX2 в гаджете спекулятивного выполнения (leak gadget) и в гаджете передачи сведений (transmit gadget) можно определить факт спекулятивного выполнения кода на основании исчезновения задержки на пробуждение блока AVX2. Указанная особенность позволяет существенно сократить число проверок для определения каждого бита информации, например, для восстановления одного байта через кэш при атаке в локальной сети требуется как миниум 30 минут, а при использовании утечки на базе AVX2 время определения можно снизить до 8 минут.


  if (x < bitstream_length)
      if(bitstream[x])
        _mm256_instruction();

Для поиска подобных гаджетов в коде ядра, библиотек и приложений можно использовать специальную утилиту. Потенциально упомянутые фрагменты кода могут встречаться в любых сетевых приложениях, в том числе в коде http-серверов, SSH и других обработчиках сетевых пакетов. При эксплуатации гаджетов в ядре можно получить полный доступ к содержимому всей системной памяти. Тем не менее, атаку усложняет то, что из-за очень низкой скорости извлечения информации для успешного получения закрытых данных, таких как ключи шифрования, нужно точно знать их смещение в памяти (при обычном переборе на извлечение 1 Мб данных потребуется 15 лет). В качестве более реалистичного применения атаки называется определение адреса, позволяющего судить о раскладке памяти при использовании ASLR (address space layout randomization) - определение адреса занимает около двух часов.

Дополнение: Инженеры Red Hat проанализировали состав дистрибутива RHEL и не выявили в числе пользовательских компонентов подходящих для атаки фрагментов кода. Также в Red Hat организован более детальный аудит сетевого стека и всех сетевых демонов, принимающих соединения по сети.

  1. Главная ссылка к новости (https://arstechnica.com/gadget...)
  2. OpenNews: Эксплуатация уязвимости в DRAM-памяти через локальную сеть
  3. OpenNews: Представлена Spectre-NG, группа из 8 новых уязвимостей в процессорах
  4. OpenNews: Найден метод обхода механизма защиты AMD Secure Encrypted Virtualization
  5. OpenNews: Два новых варианта уязвимости Spectre. Усиление защиты Chrome
  6. OpenNews: Представлена SpectreRSB, новая уязвимость в механизме спекулятивного выполнения CPU
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: spectre, memory, cache
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (36) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.4, Аноним (4), 11:52, 27/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ну подождал пару дней и получил AES. По-моему, оно того стоит.
     
     
  • 2.5, Аноним (5), 11:57, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    читай новость дальше заголовка
     
  • 2.32, Аноним (32), 16:19, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Пару лет скорее, но проблема в том что они столько могут не прожить...
     

  • 1.6, гном спецназ (?), 12:11, 27/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    пора переходить на квантовые компы..чего ждем?
     
     
  • 2.8, A.Stahl (ok), 12:39, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Никто никого не ждёт. Все, кому это нужно было, уже довольно давно перешли.
     
     
  • 3.14, Аноним (-), 13:23, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    куда перешли то? Поделия, что журналюги называют "квантовыми компухтерами" ни разу оными не является. Ъ квантовые пекарни еще ни разу не близко даже в лабораторных условиях
     
     
  • 4.23, A.Stahl (ok), 14:31, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тем не менее...
     
  • 2.9, Аноним (9), 12:46, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Они ускоряют лишь довольно узкий спектр математических задач, в крусис на них не поиграешь,  да и в любую игру
     
  • 2.12, Аноним (-), 13:17, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты уже создал такой?
     
     
  • 3.25, гном спецназ (?), 14:52, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    а ты ?
     
  • 2.46, VladSh (?), 11:15, 30/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Так не жди.
     

  • 1.7, Аноним (7), 12:22, 27/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Дополнение: Инженеры Red Hat проанализировали состав дистрибутива RHEL и не выявили в числе пользовательских компонентов подходящих для атаки фрагментов кода.

    Разве нужны ещё какие-то комментарии?

     
     
  • 2.16, Аноним (16), 13:23, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Дополнение: Инженеры Red Hat проанализировали состав дистрибутива RHEL и не выявили в числе пользовательских компонентов подходящих для атаки фрагментов кода.
    >
    > Разве нужны ещё какие-то комментарии?

    Конечно. Ждём комментариев от инженеров Arch Linux и NetBSD.

     
     
  • 3.18, Анонимный инжынер Арча (?), 13:35, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Конечно. Ждём комментариев от инженеров Arch Linux

    Основной состав инженеров сейчас ушел на речку купаться, интернет там никакой.
    Так что стейтмент будет только вечером.

     
     
  • 4.22, Попугай Кеша (?), 14:24, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Речка - это хорошо, а то красногл@зят перед этими своими компутэрами
     
     
  • 5.39, Попу гайкаша (?), 22:52, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Шел бы ты тоже на речку.
     
  • 3.19, UraniumSun (ok), 14:00, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Про NetBSD ещё можно понять, но откуда инженеры в Arch Linux?
     
     
  • 4.21, RotarenegeD (?), 14:12, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    это теже ребята что в рэдхэте, только дома..
     

  • 1.11, Иван Метель (?), 13:15, 27/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Как задолбали все эти ваши атаки... Пошел доставать счеты с чердака.
     
     
  • 2.17, Аноним (17), 13:29, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Счеты взламываются визуальной атакой через бинокль из соседнего окна.
     
     
  • 3.20, Аноним (-), 14:02, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Занавески наше все!
     
     
  • 4.24, A.Stahl (ok), 14:37, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Ты же понимаешь что разные костяшки звучат по-разному и с помощью современных технологий вполне возможно подслушать твои рассчёты?
     
     
  • 5.35, anonus (?), 20:33, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А ты не используй спекулятивные вычисления
     
  • 5.47, VladSh (?), 11:17, 30/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Сможешь удалённо определить, какая как звучит?
     

  • 1.26, ryoken (ok), 15:01, 27/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Поправьте кто в курсе вопроса. Вроде были ещё уязвимости из 1394_портов, не? Или это у меня колбаса Бородинская ("смешались в кучу кони, люди") уже..?
     
     
  • 2.33, Аноним84701 (ok), 16:25, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Поправьте кто в курсе вопроса. Вроде были ещё уязвимости из 1394_портов, не?
    > Или это у меня колбаса Бородинская ("смешались в кучу кони, люди") уже..?

    Были:
    https://marc.info/?l=bugtraq&m=109881362530790&w=2
    > Date:       2004-10-26 16:57:18
    > IEEE1394 Specification allows client devices to directly access host memory,
    > bypassing operating system limitations. A malicious client device
    > can read and modify sensitive memory, causing privilege escalation,
    > information leakage and system compromise.
    >

    Там еще через пару лет действующие PoCи демонстрировали:
    https://www.techrepublic.com/blog/it-security/the-firewire-hole/

     
  • 2.38, sage (??), 22:47, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это не уязвимость, это особенность. То же самое с Thunderbolt, там тоже DMA.

    https://github.com/ufrisk/pcileech
    https://github.com/carmaa/inception

     

  • 1.28, iPony (?), 15:43, 27/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Во все дыры уже имеют... И под хвост, и в гриву...

    А тут некоторые писали: "да это всё ерунда, и ненужно — не забирайте 10% производительности".

     
     
  • 2.34, нах (?), 16:28, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну щас тебе и это пофиксят - например, вотнув в ядро принудительную перезагрузку раз в два дня.

     
     
  • 3.36, anonus (?), 20:34, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В MS значит кто-то знал...
     
  • 2.42, Баклансбалкан (?), 23:37, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    так ведь это как-раз про понЕй... и под хвост и в гриву...
     
  • 2.44, Led (ok), 04:17, 28/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Во все дыры уже имеют... И под хвост, и в гриву...

    Ты так говоришь, поняша, как будто тебе это не нравится...

     

  • 1.37, Ordu (ok), 22:15, 27/07/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А это нельзя решить на уровне сетевой карты или где-нибудь в недрах tcp/ip стека, путём добавления рандомной задержки? Или не рандомной, а такой которая нивелирует различия? То есть, грубо говоря, если в ответ на пакет X система отправляет наружу пакет Y, и делает это за время t: t1<t<t2, то сетевушка (или tcp/ip стек) получив пакет Y откладывает его и отправляет в момент времени t2.

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

     
     
  • 2.40, Одри (?), 22:59, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема в людях, а не в софте.
     
     
  • 3.43, Ordu (ok), 23:44, 27/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Проблема в людях, а не в софте.

    И что значит сие загадочное высказывание?

     
     
  • 4.48, Аноним (48), 12:59, 30/07/2018 [^] [^^] [^^^] [ответить]  
  • +/
    возможно то, что алгоритмикой должен заниматься не человек, правильное и предсказуемое поведение определяется ветвлением на условно предсказуемых квирках
     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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