Группа исследователей из Грацского технического университета (Германия), ранее известная разработкой
метода (https://www.opennet.me/opennews/art.shtml?num=48591) эксплуатация уязвимости в DRAM-памяти через локальную сеть, опубликовала (https://misc0110.net/web/files/netspectre.pdf) описание новой атаки NetSpectre, позволяющей инициировать утечку данных из памяти через манипуляцию с сетевыми пакетами, отправляемыми по сети.
Опасность атаки сглаживается её низкой производительностью - в оптимальных условиях предложенный метод позволяет определить 15-60 бит данных в час или 45-180 байт в день. В реальных условиях скорость значительно ниже, например, тестовая атака на окружение в Google Cloud позволила извлечь лишь 1-3 байт за 3-8 часов атаки (потребовалось выполнить около 20 млн проверок для определения одного бита). Ожидается, что со временем будут предложены методы, повышающие эффективность атаки, но в любом случае на извлечение ключа AES потребуются дни. По заявлению компании Intel атака блокируется методами защиты, предложенными (https://software.intel.com/sites/default/files/managed/c5/63...) для первого варианта уязвимости Spectre (CVE-2017-5753).
Метод атаки основывается на наличии в коде типовых программ и ядра фрагментов кода (гаджетов), приводящих к спекулятивному обращению к областям памяти ("leak gadget") и раскрытию информации ("transmit gadget") по сети. Например, во многих приложениях встречаются конструкции вида (важно само обращение к bitstream[x] после проверки границ):if (x
Если подобные фрагменты применяются при обработке сетевых пакетов и атакующий может передать пакет, в котором значение "x" выходит за пределы допустимых значений, то появляется возможность инициирования спекулятивного обращения к областям памяти вне допустимых границ. Результат данных спекулятивных операций отбрасывается процессором, но оседает в кэше и доступен для извлечения при помощи методов анализа содержимого кэша по сторонним каналам. Для успешного спекулятивного выполнения перед передачей выходящего за границы значения "x" требуется предварительно натренировать блок предсказания переходов корректными значениями, в этом случае сработает оптимизация по спекулятивному обращению к памяти до того как станет известен результат проверки условного оператора.
Для определения остаточных данных также предлагается использовать существующие фрагменты кода в приложениях и ядре ("transmit gadget"), которые активируются при поступлении определённых видов сетевых запросов. Например, для извлечения осевших в кэше данных исследователями предложена модификация метода Evict+Reload (https://cryptologie.net/article/367/ches-2016-tutorial-part-.../), основанного на создании условий для вытеснения данных из кэша (например, создаётся сетевая активность равномерно заполняющая кэш типовым содержимым) и обработки запросов, время выполнения которых позволяет судить о наличии данных в процессорном кэше. Скорость проведения подобной атаки по сети не превышает 15 бит в час.Для повышения производительности до 60 бит в час исследователи предложили использовать гаджеты с инструкциями AVX2 в качестве дополнительного канала утечки информации. Метод основан на особенностях перевода блока AVX2 в режим энергосбережения. В случае неактивного использования AVX2 предусмотрен режим экономии энергии, при котором блок AVX2 продолжает работать, но снижается его производительность. В случае неактивности AVX2 в течение 1 мс процессор полностью отключает блок AVX2, что приводит к появлению заметной задержки при выполнении следующей операции.
При использовании инструкций AVX2 в гаджете спекулятивного выполнения (leak gadget) и в гаджете передачи сведений (transmit gadget) можно определить факт спекулятивного выполнения кода на основании исчезновения задержки на пробуждение блока AVX2. Указанная особенность позволяет существенно сократить число проверок для определения каждого бита информации, например, для восстановления одного байта через кэш при атаке в локальной сети требуется как миниум 30 минут, а при использовании утечки на базе AVX2 время определения можно снизить до 8 минут.
if (xДля поиска подобных гаджетов в коде ядра, библиотек и приложений можно использовать специальную утилиту (https://access.redhat.com/blogs/766093/posts/3510331). Потенциально упомянутые фрагменты кода могут встречаться в любых сетевых приложениях, в том числе в коде http-серверов, SSH и других обработчиках сетевых пакетов. При эксплуатации гаджетов в ядре можно получить полный доступ к содержимому всей системной памяти. Тем не менее, атаку усложняет то, что из-за очень низкой скорости извлечения информации для успешного получения закрытых данных, таких как ключи шифрования, нужно точно знать их расположение в памяти (при обычном переборе на извлечение 1 Мб данных потребуется 15 лет). В качестве более реалистичного применения атаки называется определение адреса, позволяющего судить о раскладке памяти при использовании ASLR (address space layout randomization) - определение адреса занимает около двух часов.
URL: https://arstechnica.com/gadgets/2018/07/new-spectre-attack-e.../
Новость: https://www.opennet.me/opennews/art.shtml?num=49032
Ну подождал пару дней и получил AES. По-моему, оно того стоит.
читай новость дальше заголовка
Пару лет скорее, но проблема в том что они столько могут не прожить...
пора переходить на квантовые компы..чего ждем?
Никто никого не ждёт. Все, кому это нужно было, уже довольно давно перешли.
куда перешли то? Поделия, что журналюги называют "квантовыми компухтерами" ни разу оными не является. Ъ квантовые пекарни еще ни разу не близко даже в лабораторных условиях
Тем не менее...
Они ускоряют лишь довольно узкий спектр математических задач, в крусис на них не поиграешь, да и в любую игру
Ты уже создал такой?
а ты ?
Так не жди.
> Дополнение: Инженеры Red Hat проанализировали состав дистрибутива RHEL и не выявили в числе пользовательских компонентов подходящих для атаки фрагментов кода.Разве нужны ещё какие-то комментарии?
>> Дополнение: Инженеры Red Hat проанализировали состав дистрибутива RHEL и не выявили в числе пользовательских компонентов подходящих для атаки фрагментов кода.
>
> Разве нужны ещё какие-то комментарии?Конечно. Ждём комментариев от инженеров Arch Linux и NetBSD.
> Конечно. Ждём комментариев от инженеров Arch LinuxОсновной состав инженеров сейчас ушел на речку купаться, интернет там никакой.
Так что стейтмент будет только вечером.
Речка - это хорошо, а то красногл@зят перед этими своими компутэрами
Шел бы ты тоже на речку.
Про NetBSD ещё можно понять, но откуда инженеры в Arch Linux?
это теже ребята что в рэдхэте, только дома..
Как задолбали все эти ваши атаки... Пошел доставать счеты с чердака.
Счеты взламываются визуальной атакой через бинокль из соседнего окна.
Занавески наше все!
Ты же понимаешь что разные костяшки звучат по-разному и с помощью современных технологий вполне возможно подслушать твои рассчёты?
А ты не используй спекулятивные вычисления
Сможешь удалённо определить, какая как звучит?
Поправьте кто в курсе вопроса. Вроде были ещё уязвимости из 1394_портов, не? Или это у меня колбаса Бородинская ("смешались в кучу кони, люди") уже..?
> Поправьте кто в курсе вопроса. Вроде были ещё уязвимости из 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/
Это не уязвимость, это особенность. То же самое с Thunderbolt, там тоже DMA.https://github.com/ufrisk/pcileech
https://github.com/carmaa/inception
Во все дыры уже имеют... И под хвост, и в гриву...А тут некоторые писали: "да это всё ерунда, и ненужно — не забирайте 10% производительности".
ну щас тебе и это пофиксят - например, вотнув в ядро принудительную перезагрузку раз в два дня.
В MS значит кто-то знал...
так ведь это как-раз про понЕй... и под хвост и в гриву...
> Во все дыры уже имеют... И под хвост, и в гриву...Ты так говоришь, поняша, как будто тебе это не нравится...
А это нельзя решить на уровне сетевой карты или где-нибудь в недрах tcp/ip стека, путём добавления рандомной задержки? Или не рандомной, а такой которая нивелирует различия? То есть, грубо говоря, если в ответ на пакет X система отправляет наружу пакет Y, и делает это за время t: t1<t<t2, то сетевушка (или tcp/ip стек) получив пакет Y откладывает его и отправляет в момент времени t2.То есть, понятно, что вся эта возня с организацией очереди пакетов, упорядоченной по планируемому времени отправки, может повлиять на производительность, но так ли она повлияет? И, в конце-концов, эту очередь можно реализовать в железе на стороне сетевушки.
Проблема в людях, а не в софте.
> Проблема в людях, а не в софте.И что значит сие загадочное высказывание?
возможно то, что алгоритмикой должен заниматься не человек, правильное и предсказуемое поведение определяется ветвлением на условно предсказуемых квирках