The OpenNET Project / Index page

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

SQUIP - атака на процессоры AMD, приводящая к утечке данных по сторонним каналам

12.08.2022 07:26

Группа исследователей из Грацского технического университета (Австрия), ранее известная разработкой атак MDS, NetSpectre, Throwhammer и ZombieLoad, раскрыла сведения о новом методе атаки по сторонним каналам (CVE-2021-46778) на очереди планировщика процессоров AMD, применяемые для планирования выполнения инструкций в разных исполнительных блоках CPU. Атака, получившая название SQUIP, позволяет определить используемые при вычислениях в другом процессе или виртуальной машине данные или организовать скрытый канал связи между процессами или виртуальными машинами, позволяющий обмениваться данными в обход системных механизмов разграничения доступа.

Проблеме подвержены CPU AMD на базе микроархитектур Zen первого, второго и третьего поколений (AMD Ryzen 2000-5000, AMD Ryzen Threadripper, AMD Athlon 3000, AMD EPYC) при использовании технологии одновременной многопоточности (SMT). Процессоры Intel атаке не подвержены, так как в них используется одна очередь планировщика, в то время как в уязвимых процессорах AMD для каждого исполнительного блока применяются отдельные очереди. В качестве обходного пути для блокирования утечки информации компания AMD рекомендовала разработчикам использовать алгоритмы, математические вычисления в которых всегда выполняются за постоянное время, независимо от характера обрабатываемых данных, а также избегать ветвления на основе секретных данных.

Атака основана на оценке уровня возникновения конфликтов (contention level) в разных очередях планировщика и проводится через измерение задержек при запуске проверочных операций, выполняемых в другом потоке SMT на том же физическом CPU. Для анализа содержимого использован метод Prime+Probe, подразумевающий заполнение очереди эталонным набором значений и определение изменений через измерение времени доступа к ним при повторном заполнении.

В ходе эксперимента исследователям удалось полностью воссоздать закрытый 4096-битовый RSA-ключ, используемый для создания цифровых подписей при помощи криптографической библиотеки mbedTLS 3.0, в которой для возведении числа в степень по модулю применяется алгоритм Монтгомери. Для определения ключа потребовалось выполнить 50500 трассировок. Общее время атаки заняло 38 минут. Продемонстрированы варианты атаки, обеспечивающие утечку между разными процессами и виртуальными машинами, управляемыми гипервизором KVM. Также показано, что метод можно использовать для организации скрытой передачи данных между виртуальными машинами со скоростью 0.89 Mbit/s и между процессами со скоростью 2.70 Mbit/s при уровне ошибок менее 0.8%.

  1. Главная ссылка к новости (https://www.theregister.com/20...)
  2. OpenNews: Уязвимость в механизме спекулятивного выполнения инструкций процессоров AMD
  3. OpenNews: В процессорах AMD выявлена ещё одна уязвимость, допускающая атаки класса Meltdown
  4. OpenNews: В процессорах AMD на базе микроархитектур Zen+ и Zen 2 обнаружена уязвимость класса Meltdown
  5. OpenNews: Уязвимость в специфичном для CPU AMD коде KVM, позволяющая выполнить код вне гостевой системы
  6. OpenNews: Две атаки на механизм предсказания каналов кэша в процессорах AMD
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/57629-amd
Ключевые слова: amd, attack
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (96) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Шарп (ok), 08:34, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >проводится через измерение задержек

    Все эти атаки схожи в использовании точного таймера для измерения времени. Может лучше его загрубить, чем портить производительность очередными патчами?

    >Общее время атаки заняло 38 минут

    Менять ключ каждые 30 минут. Шах и мат аметисты^Wисследователи.

     
     
  • 2.5, pashev.ru (?), 08:39, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Понадобится больше времени для сбора статистики для устранения шума таймера.
     
     
  • 3.13, Онаним (?), 09:28, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В реальной жизни ты этот шум не устранишь никак, потому что помимо твоего лабораторного процесса активно исполняется пачка других. И это уже о шаредах/VPS не говоря.
     
     
  • 4.15, Онаним (?), 09:30, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я чуть промахнулся - я не о шуме таймера, а о шуме результатов измерения.
     
  • 3.16, Онаним (?), 09:32, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Если к этому дополнительно ещё и таймер действительно загрубить - то всё, все эти лабораторные атаки работать перестанут. Я бы вообще чуть-чуть частоту ядер "гулял" во времени непрерывно, чтобы замерить что-то было невозможно.
     
     
  • 4.18, pashev.ru (?), 09:51, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > ещё и таймер действительно загрубить

    Прошу прощения, но например чёткие фотки дальнего космоса получают с помощью весьма нечёткое аппаратуры.

     
     
  • 5.54, Онаним (?), 18:28, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разница в том, что космос наблюдается непрерывно, а алгоритм с нужным ключиком - раз в пятилетку (по меркам машинного времени), чтобы столько данных для усреднения насобирать - годы уйдут. Оно и без загрубления то с 50500 раза собирается )
     
  • 4.22, Rev (?), 10:40, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Я бы вообще чуть-чуть частоту ядер "гулял" во времени непрерывно

    Так частоты и так постоянно туда-сюда бегают.

     
     
  • 5.53, Онаним (?), 18:27, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Оно бегает, но не непрерывно. А если иметь в виду защиту от тайминг-атак - должно бегать непрерывно. В очень небольших пределах, там на приличный размер алгоритма достаточно шума, сопоставимового с единичным обращением к памяти, чтобы тайминг-атаки отвалились.
     
  • 2.6, pashev.ru (?), 08:41, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Менять ключ каждые 30 минут

    Letsencrypt одобряет!

     
     
  • 3.76, FSA (??), 13:50, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Letsencrypt одобряет!

    А что с ним не так? Сертификат на 3 месяца, который сам обновляется. Если что не так, тебя за месяц предупреждают. Вполне достаточно, чтобы выпрямить руки и переставить на место. Гораздо лучше, чем через год или три неожиданно обнаружить, что у тебя сертификат протух и судорожно вспоминать где и как ты его получал.

     
     
  • 4.118, Брат Анон (ok), 12:18, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ключ 4096 бит подбирается меньше чем за час. А сертификат выдаётся на ТРИ МЕСЯЦА. Действительно, что не так-то?!
     
     
  • 5.126, Самый Лучший Гусь (?), 13:47, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У населения на руках нет такого железа, чтобы подбирать такие ключи. А у тех кто есть можно и отобрать, я точно против не буду.
     
     
  • 6.128, Брат Анон (ok), 15:20, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > У населения на руках нет такого железа, чтобы подбирать такие ключи. А
    > у тех кто есть можно и отобрать, я точно против не
    > буду.

    Неужели у населения нет ноутбуков и стационарных ПК на базе х86_64?... Вот это новость!!!
    Ааа... Я понял: у них процы на столько слабые, что не способны выполнить 50к запросов за полчаса.

    Вы новость точно читали?

     
  • 2.9, Аноним (9), 08:47, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Все эти атаки схожи в использовании точного таймера для измерения времени. Может лучше его загрубить, чем портить производительность очередными патчами?

    https://gruss.cc/files/fantastictimers.pdf - от этих же товарищей

     
  • 2.68, Аноним (68), 23:23, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Может лучше его загрубить, чем портить производительность очередными патчами?

    Не, ну вы интересный персонаж!
    Если бы вы работали в АМD, вас бы выкинули за такие идеи, как в том комиксе.
    А кто будет лохам новые "неподверженные атакам" модели продавать?! Святая простота.

     

  • 1.4, Кактус (?), 08:34, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Сообщения о новых уязвимостях в процессорах скоро станут ежедневно сопровождать новости, как погода и курсы валют
     
     
  • 2.7, Аноним (7), 08:42, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    хакер и солонка. Люди старались, ускоряли процы, но нет, найдется кто-то, кто найдет якобы "уязвимость" и вернет мощности процов взад во времена 1999.
     
     
  • 3.35, Аноним (35), 12:46, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И будет при этом сча́стливо лы́бится? )
     
  • 3.47, Аноним (47), 16:53, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >хакер и солонка

    Вместо того, чтобы пытаться заштопать дырки и создать защищённую солонку, можно выдавать соль и перец в отдельных бумажных пакетиках, как это и делают в общепите

     
     
  • 4.78, Аноним (78), 15:07, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Что мешает подменить бумажные пакетики своими?
     
     
  • 5.116, Бывалый смузихлёб (?), 08:47, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что мешает подменить бумажные пакетики своими?

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

     
  • 3.63, Аноним (63), 20:31, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А почему "якобы"? Всякие эксплоиты, эксплуатирующие дырки в спекулятивности, вполне себе рабочие.
     
     
  • 4.79, Аноним (78), 15:07, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И много _реальных_ данных с их помощью добыли?
     
  • 3.65, Аноним (65), 21:54, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Люди старались, ускоряли процы

    люди писали костыли, срезали углы и полагались на авось лишь бы выпустить и продать новое поколение +5%

     
  • 3.119, Брат Анон (ok), 12:20, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Смех смехом. Но это пока дело до войны не дошло. Когда во время войны будет отравлен в полном составе какой-нибудь оборонный завод.

    Прецеденты ранее уже были. https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%80

     

  • 1.8, Аноним (8), 08:43, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >Общее время атаки заняло 38 минут

    Очень практический кейс. Исследователям премии, надеюсь, уже выписали

     
     
  • 2.20, Аноним (20), 09:53, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    а чё, дольше 37 минут закон запрещает атаковать?
     
     
  • 3.28, Аноним (8), 11:31, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Опеннет комментаторы как всегда. 38 минут на очень специфический лабораторный тест кейс из пробирки, где все параметры ключа известны заранее, и нет никаких параллельных задач
     

  • 1.10, Аноним (10), 09:18, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Пришло время оптимизировать софт, чтобы ему хватало и более медленных процессоров.
     
     
  • 2.24, Аноним (24), 10:50, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Пришло время переписывать софт на C, чтобы ему хватало и более медленных процессоров.

    Поправил.

     
     
  • 3.93, Аноним (93), 16:31, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда дыры в процессорах никому не нужны будут.
     
     
  • 4.114, Аноним (114), 20:31, 14/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что можно взять много процессоров.
     
  • 3.120, Брат Анон (ok), 12:23, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пришло время использовать нормальный язык с созданный под него нормальный проц.
    (* Нет не Си, не Раст, не питон *)

    Поправил.

     
  • 2.30, Аноним (30), 11:43, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не дождётесь. Мы лучше будем пускать виртуалку в виртуалке - в виртуалке - ... - на большом кластере из простых ядер (без спекулятитвов), чтобы усложнить жизнь сторонним каналам.
     
  • 2.39, YetAnotherOnanym (ok), 13:15, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И чтобы алгоритмы выполнялись за фиксированное время.
     
     
  • 3.43, Аноним (24), 14:12, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ОС РВ открыли
     
     
  • 4.62, YetAnotherOnanym (ok), 20:20, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Моей заслуги тут нет, это всё специалисты АМД:
    > компания AMD рекомендовала разработчикам использовать алгоритмы, математические вычисления в которых всегда выполняются за постоянное время, не зависимо от характера обрабатываемых данных
     
  • 4.67, Michael Shigorin (ok), 22:11, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Там про уложиться в таймслот _сверху_.
    А тут -- про и сверху, и снизу.
     
     
  • 5.97, Аноним (97), 17:31, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Снизу можно добавить недостающей паузы.
     

  • 1.11, Онаним (?), 09:26, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    "Для определения ключа потребовалось выполнить 50500 трассировок. Общее время атаки заняло 38 минут."
    В лабораторных условиях без сторонней нагрузки. Расходимся, интел-фанбои опять облажались.
     
  • 1.14, Онаним (?), 09:29, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Меня только одно напрягает: сейчас в ведро опять каких-нибудь заляпок насуют. Включение mitigations=off уже стало насущной необходимостью, а по мере увеличения количества заляпок видимо придётся штатные ядра из дистров перебирать с правкой конфига, потому что чеки всех этих заляпок тоже не бесплатные.
     
     
  • 2.121, Брат Анон (ok), 12:24, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не используйте забугорные изделия. Ни процы, ни тем более шиндошс.
     

  • 1.17, Аноним (17), 09:38, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    И не помогут тебе, сынок, ни раст, ни карбон, ни даже эльбрус! Только святой 486 с влб шиной, только хардкор!
     
     
  • 2.31, Аноним (30), 11:53, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    VLB защиты от утечек в проце не добавляет, поэтоту можно PCI-E. А ядра CPU можно и попроще, чем 486, но побольше количеством.
     
     
  • 3.32, PnD (??), 12:19, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И "солярку" (в девичестве SunOS) взад вернуть. Она как раз под такой кейс была заточена. "Но что-то пошло не так."
     
  • 3.94, Аноним (93), 16:33, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы только что придумали графический ускоритель. Круг задач решаемый которым весьма ограничен.
     
  • 2.48, Бывалый смузихлёб (?), 16:56, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну вот как раз Эльбрус возможно и поможет..
     
     
  • 3.57, Аноним (65), 18:51, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Только ты его не купишь, ахахаха (с)
     
     
  • 4.66, Michael Shigorin (ok), 22:09, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему?

    http://imaxai.ru -- материнки (внимание, 8С весьма придирчив по части DDR3)
    http://bitblaze.ru -- системы

    Кому много -- http://norsi-trans.ru

    PS: моя домашняя машинка, если что -- "Эльбрус-16С".

    PPS: есть тут нынче линуксоводы из .kz? :) (про давнего оппонента помню, но его почерк давно уж не примечал так чтоб явно)

     
     
  • 5.71, Аноним (71), 09:42, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Такое старьё я бы даже при наличии лишних денег не стал покупать. Что там слышно про 32с? Всё заглохло?
     
  • 5.95, Аноним (93), 16:35, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Материнская плата E8C-mITX на базе Эльбрус-8С и 2D-видео
    Самая доступная плата на Эльбрус-8С
    254 500 ₽

    Я что-то ржал

     
     
  • 6.115, мимо (?), 04:17, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    За 250к собирается 5950x c 128Гб ram и nvme рейдом. Вместе с коропусом, бп и охлаждением.
    САМАЯ ДОСТУПНАЯ ПАЛАТА
     
  • 5.122, Брат Анон (ok), 12:28, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет. Для дома такое не купишь. Даже с моей зарплатой.

    "Купить" -- означает придёшь в каждый второй магазин и там оно лежит в свободной продаже по конкурентной цене. Даже с падением производительности в 10 раз -- в целях безопасности я готов купить. Но безопасность сомнительна, цена конская, куча других компонентов ,которые никак не гарантируют безопасность.

    Увы, но это полумера.

     

  • 1.19, Аноним (20), 09:52, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    как только zen 4 вышел, сразу в первых трёх поколениях уязвимость нашли, ага
     
     
  • 2.36, Аноним (36), 12:47, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Про уязвимости процессоров знает очень мало покупателей. Для кого эта информация? Явно не для них.
     
     
  • 3.41, Аноним (30), 14:10, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Мракетинг поможет им узнать ;)
     
  • 2.77, Аноним (-), 14:27, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Что говорит, что в zen 4 они скорее всего тоже есть, но исследователи не успели его купить, чтобы проверить.
     

  • 1.21, Аноним (21), 10:04, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Эти дыры уже перешли в категорию хакера и солонки.
     
     
  • 2.23, Аноним (23), 10:49, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Только это не солонка, а проц.
     
     
  • 3.56, Аноним (56), 18:38, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Солонка то, поопаснее будет...
     
     
  • 4.103, Аноним (-), 19:16, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сравнения некоректны!
    А выдавать соль и перец нужно в отдельных бумажных пакетиках, как это и делают в общепите.
     
     
  • 5.117, Бывалый смузихлёб (?), 08:52, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Сравнения некоректны!
    > А выдавать соль и перец нужно в отдельных бумажных пакетиках, как это
    > и делают в общепите.

    в общепите( те же столовые ) очень даже и солонки и перечницы стоят. Если повезёт - так и бутылки с соевым соусом и кетчупом на столе будут стоять

     

  • 1.25, InuYasha (??), 10:55, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А как там поживают K10, Bulldozer и Pile-Driver? Не тестировали?
     
  • 1.26, Анонус (?), 11:00, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Мне показалось, или бОльшую часть процессорных уязвимостей находят в европейских университетах? То ли у них требования к безопасности выше, то ли заняться нечем.
     
     
  • 2.27, Аноним (20), 11:19, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    в американских тоже. прям завидую такой системе образования, хотел бы там учиться. в MIT в каком-нибудь
     
  • 2.82, Аноним (-), 15:22, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Мне показалось, или бОльшую часть процессорных уязвимостей находят в европейских университетах? То ли у них требования к безопасности выше, то ли заняться нечем.

    У них скорее больше свободы этим заниматься и открыто публиковать результаты. В РФ, к примеру, подобными исследованиями независимо заниматься фактически невозможно  вообще. На всем, что с безопасностью связано сплошной интерес фсб.

     
  • 2.110, Аноним (110), 12:36, 14/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В других местах такие уязвимости секретят и используют в своих целях. А в европейский спецслужбам такое нафиг не надо. Ну серьёзно ты считаешь что Австрия решила стать мировым гигемоном? Да там и спецслужбы то для вида существуют. Вот и выкладывают уязвимости в открытый доступ.

    И ещё кстати это маркер что уязвимости такие простые что из может обнаружить простой студент!

     
  • 2.123, Брат Анон (ok), 12:30, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне показалось, или бОльшую часть процессорных уязвимостей находят в европейских университетах?
    > То ли у них требования к безопасности выше, то ли заняться
    > нечем.

    Не показалось. Америка пытается продавать себя как может. А публикуя каждый месяц сообщения о проблемах в железе -- лохов не разведёшь.

     
  • 2.130, Анонус (?), 23:09, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Не находят, им говорят когда оглашать нужную инфу
     

  • 1.33, darkshvein (ok), 12:31, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >Процессоры Intel атаке не подвержены, так как в них используется одна очередь планировщика,

    а я всегда знал, что интел однозадачный

     
     
  • 2.38, Аноним (35), 12:54, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://avatars.mds.yandex.net/get-mpic/5418200/img_id6418693241783813263.jpeg
     

  • 1.40, Аноним (40), 13:30, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Не подключайтесь к сети, пишите всё ПО сами, включая ОС и компиляторы, и никто вас не взломает.
     
     
  • 2.45, Аноним (45), 15:53, 12/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Это сложновато, даже TempleOS запускалась в виртуальной машине на убунту, что уж говорить об не особо энергичных людях.
     
     
  • 3.111, Аноним (110), 12:37, 14/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да он псих был.  
     
  • 2.124, Брат Анон (ok), 12:32, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не подключайтесь к сети, пишите всё ПО сами, включая ОС и компиляторы,
    > и никто вас не взломает.

    В твоих словах анон нет логики. Самое главное забыл -- железо. А если железо, ПО, включая оС и компиляторы -- своё -- тогда зачем отключаться?...

     

  • 1.61, Аноним (61), 19:53, 12/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > компания AMD рекомендовала разработчикам использовать алгоритмы, математические вычисления в которых всегда выполняются за постоянное время, не зависимо от характера обрабатываемых данных, а также избегать ветвления на основе секретных данных

    Годный совет безотносительно утечек.

     
     
  • 2.72, Онаним (?), 10:38, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чем он годный-то? Фиксированное время выполнения может упростить тайминг-атаку на кеши например.
    Самый годный вариант - это алгоритмы с независимым от данных (псевдо)случайным временем выполнения, т.е. разбавленный небольшими рандомными (желательно с софт-независимой энтропией) задержками. Из этого что-то выцарапать будет совсем сложно.
     
     
  • 3.75, Аноним (75), 13:14, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А работать будет совсем медленно.
     
     
  • 4.86, Онаним (?), 15:37, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    С чего бы.
    Наши любимые "сторонние каналы" базируются на измерении либо времени работы критичного участка алгоритма, либо (если мы о всяких атаках на кеши) - время обращения к памяти, пытаясь определить, попали мы пальцем в ж..., простите, в кеш, или в память.
    В первом случае всё потяжелее - нам надо рандом, сопоставимый с временем выполнения алгоритма. Т.е. в худшем случае мы это время удваиваем. Во втором всё просто. Шум, сопоставимый с 1-2 обращениями к памяти, сводит любые попытки это померить на нет.
     
  • 3.84, Аноним (-), 15:23, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Судя по твоим комментам здесь, ты считаешь рандом способом уберечься от измерени... большой текст свёрнут, показать
     
     
  • 4.85, Онаним (?), 15:34, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ты путаешь тёплое с мягким.
    Если у тебя уровень шума начинает превышать уровень полезного сигнала - всё, ничего ты уже не восстановишь, если не используешь шумоспецифичный фильтр. Который в случае рандома с примесью допустим хардварной энтропии не вырисовывается.
     
     
  • 5.99, Аноним (-), 17:46, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Если у тебя уровень шума начинает превышать уровень полезного сигнала

    В моём примере превышает, и это не мешает.

    > шумоспецифичный фильтр

    Я намеренно генерацию рандома с нормальным распределением выделил в отдельную функцию. Попробуй воткнуть туда что-нибудь другое. Единственное усложнение, с которым тебе придётся столкнуться, это вычисление среднего значения шума. То есть такого m, что если x_n рандомное число, то \sum (x_n-m)  будет сходиться по вероятности к нулю, при n стремящимся к бесконечности.

    > Который в случае рандома с примесью допустим хардварной энтропии не вырисовывается.

    Прекрати поклоняться ложным идолам. Рандом -- не Бог, он не всемогущ. Он подчиняется статистическим закономерностям, типа закона больших чисел.

     
  • 4.87, Онаним (?), 15:39, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И заметь, что ты работаешь не с изменённым исходным сигналом, а пытаешься восстановить сигнал по косвенным факторам, что в корне отличается от приведённого тобой примера, где сигнал модулирован.
     
     
  • 5.102, Аноним (102), 19:07, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И что математический аппарат то и там и там одинаковый.
     
     
  • 6.106, Онаним (?), 21:07, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Только потребность в N различается на порядок порядков, а так ничего.
     
  • 4.90, Онаним (?), 15:54, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ну и предлагаю подумать вот на какую тему: с фига ли эти "эксплоиты" работают с 50500 раза, и только в лабораторных условиях, без стороннего шума, если всё так легко восстанавливается усреднением? А вот с того фига так и работает, что малейший лишний шум, и всё.
     
  • 4.91, Онаним (?), 15:56, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И да, я не заметил, но с хера ли там шум аж строгого гауссового распределения будет?
    Короче опять какие-то далёкие от реальности отмашки.
     
  • 4.92, Онаним (?), 16:01, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чёт меня реально подгорело с этого маразма.
    Гауссово распределение тем и хорошо, что оно сферическое в вакууме, и на каждый +x найдётся -x, соответственно чем больше N, тем больше шанс полной компенсации и меньше остаток.
    В реальном же аппаратном шуме ты всегда получишь некоторый офсет, который в случае попытки замерить не известных характеристик сигнал тебе компенсировать абсолютно нечем. И потенциальный офсет замерить тоже нечем.
    Впрочем, даже если это откинуть - при превышающем уровень сигнала шуме тебе надо будет огроменные N, чтобы этот шум компенсировать, и все эксплоиты потребуют огромного времени для получения более-менее достоверного байта информации, чего уже вполне достаточно.
     
     
  • 5.100, Аноним (-), 17:55, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Я тоже хотел это сказать, но ты раньше успел Да, это практическая проблема Но,... большой текст свёрнут, показать
     

  • 1.69, Аноним (69), 01:52, 13/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    перешел по ссылке на оригинал https://stefangast.eu/papers/squip.pdf
    VMware вообще нет, хотя это большая часть в Enterprise, в References есть Xen и Hyper-V, Xen даже вскользь в теле статьи (cross-VM: KVM/Xen doesn't support rdpru) - и совершенно непонятно в итоге, кроме как между KVM виртуалками этот эксплойт применим вообще?
     
  • 1.70, Proddik (?), 06:23, 13/08/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    В EPYC насколько мне известно есть аппаратное шифрование памяти AES, что по идее не может давать считать данные в открытую по стороним каналам?! Или в новости EPYC указан просто так и на этих процах не проводилась атака?
     
     
  • 2.83, Аноним (83), 15:23, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Предположу, зашифрованные они только в памяти. Не могут же зашифрованные данные находиться в планировщике - с такими данными нельзя работать.
     
  • 2.98, Аноним (97), 17:34, 13/08/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Когда содержимое памяти попало в кеш или в какие промежуточные регистры в ЦПУ, оно там расшифровано.
     
     
  • 3.131, Аноним (131), 02:51, 17/08/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Предположу, что в L3 & L2 зашифрованный данные попасть могут. Насчёт L1 - скорее всего, тоже. Речь ведь не о кеше микроопераций, а данных.
     
  • 2.125, Брат Анон (ok), 12:35, 15/08/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В EPYC насколько мне известно есть аппаратное шифрование памяти AES, что по
    > идее не может давать считать данные в открытую по стороним каналам?!
    > Или в новости EPYC указан просто так и на этих процах
    > не проводилась атака?

    Если данные ВСЕГДА зашифрованы -- как их тогда использовать?
    Процессор не умеет работать с зашифрованными данными (и кеш тоже). Для этого надо такой огород городить, что площадь кристалла раздует кратно. И всё-равно будет фаза расшифрованных данных.

    Вопрос решается по другому: своя гарантированно надёжная, изолированная, тупая железка. Которые свои ключи не отдаёт никогда и никому.

     

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



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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