Группа исследователей из Грацского технического университета (Австрия), ранее известная разработкой атак MDS, NetSpectre, Throwhammer и ZombieLoad, раскрыла сведения о новом методе атаки по сторонним каналам (CVE-2021-46778) на очереди планировщика процессоров AMD, применяемые для планирования выполнения инструкций в разных исполнительных блоках CPU. Атака, получившая название SQUIP, позволяет определить используемые при вычислениях в другом процессе или виртуальной машине данные или организовать скрытый канал связи между процессами или виртуальными машинами, позволяющий обмениваться данными в обход системных механизмов разграничения доступа...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57629
>проводится через измерение задержекВсе эти атаки схожи в использовании точного таймера для измерения времени. Может лучше его загрубить, чем портить производительность очередными патчами?
>Общее время атаки заняло 38 минут
Менять ключ каждые 30 минут. Шах и мат аметисты^Wисследователи.
Понадобится больше времени для сбора статистики для устранения шума таймера.
В реальной жизни ты этот шум не устранишь никак, потому что помимо твоего лабораторного процесса активно исполняется пачка других. И это уже о шаредах/VPS не говоря.
Я чуть промахнулся - я не о шуме таймера, а о шуме результатов измерения.
Если к этому дополнительно ещё и таймер действительно загрубить - то всё, все эти лабораторные атаки работать перестанут. Я бы вообще чуть-чуть частоту ядер "гулял" во времени непрерывно, чтобы замерить что-то было невозможно.
> ещё и таймер действительно загрубитьПрошу прощения, но например чёткие фотки дальнего космоса получают с помощью весьма нечёткое аппаратуры.
Разница в том, что космос наблюдается непрерывно, а алгоритм с нужным ключиком - раз в пятилетку (по меркам машинного времени), чтобы столько данных для усреднения насобирать - годы уйдут. Оно и без загрубления то с 50500 раза собирается )
> Я бы вообще чуть-чуть частоту ядер "гулял" во времени непрерывноТак частоты и так постоянно туда-сюда бегают.
Оно бегает, но не непрерывно. А если иметь в виду защиту от тайминг-атак - должно бегать непрерывно. В очень небольших пределах, там на приличный размер алгоритма достаточно шума, сопоставимового с единичным обращением к памяти, чтобы тайминг-атаки отвалились.
> Менять ключ каждые 30 минутLetsencrypt одобряет!
> Letsencrypt одобряет!А что с ним не так? Сертификат на 3 месяца, который сам обновляется. Если что не так, тебя за месяц предупреждают. Вполне достаточно, чтобы выпрямить руки и переставить на место. Гораздо лучше, чем через год или три неожиданно обнаружить, что у тебя сертификат протух и судорожно вспоминать где и как ты его получал.
Ключ 4096 бит подбирается меньше чем за час. А сертификат выдаётся на ТРИ МЕСЯЦА. Действительно, что не так-то?!
У населения на руках нет такого железа, чтобы подбирать такие ключи. А у тех кто есть можно и отобрать, я точно против не буду.
> У населения на руках нет такого железа, чтобы подбирать такие ключи. А
> у тех кто есть можно и отобрать, я точно против не
> буду.Неужели у населения нет ноутбуков и стационарных ПК на базе х86_64?... Вот это новость!!!
Ааа... Я понял: у них процы на столько слабые, что не способны выполнить 50к запросов за полчаса.Вы новость точно читали?
>Все эти атаки схожи в использовании точного таймера для измерения времени. Может лучше его загрубить, чем портить производительность очередными патчами?https://gruss.cc/files/fantastictimers.pdf - от этих же товарищей
>Может лучше его загрубить, чем портить производительность очередными патчами?Не, ну вы интересный персонаж!
Если бы вы работали в АМD, вас бы выкинули за такие идеи, как в том комиксе.
А кто будет лохам новые "неподверженные атакам" модели продавать?! Святая простота.
Сообщения о новых уязвимостях в процессорах скоро станут ежедневно сопровождать новости, как погода и курсы валют
хакер и солонка. Люди старались, ускоряли процы, но нет, найдется кто-то, кто найдет якобы "уязвимость" и вернет мощности процов взад во времена 1999.
И будет при этом сча́стливо лы́бится? )
>хакер и солонкаВместо того, чтобы пытаться заштопать дырки и создать защищённую солонку, можно выдавать соль и перец в отдельных бумажных пакетиках, как это и делают в общепите
Что мешает подменить бумажные пакетики своими?
> Что мешает подменить бумажные пакетики своими?идея на миллион - переть со столовой их пакетики, подменяя собственными такими же, но купленными в розницу
А почему "якобы"? Всякие эксплоиты, эксплуатирующие дырки в спекулятивности, вполне себе рабочие.
И много _реальных_ данных с их помощью добыли?
> Люди старались, ускоряли процылюди писали костыли, срезали углы и полагались на авось лишь бы выпустить и продать новое поколение +5%
Смех смехом. Но это пока дело до войны не дошло. Когда во время войны будет отравлен в полном составе какой-нибудь оборонный завод.Прецеденты ранее уже были. https://ru.wikipedia.org/wiki/%D0%9F%D0%...,_%D0%97%D0%B8%D0%BD%D0%B0%D0%B8%D0%B4%D0%B0_%D0%9C%D0%B0%D1%80%D1%82%D1%8B%D0%BD%D0%BE%D0%B2%D0%BD%D0%B0
>Общее время атаки заняло 38 минутОчень практический кейс. Исследователям премии, надеюсь, уже выписали
а чё, дольше 37 минут закон запрещает атаковать?
Опеннет комментаторы как всегда. 38 минут на очень специфический лабораторный тест кейс из пробирки, где все параметры ключа известны заранее, и нет никаких параллельных задач
Пришло время оптимизировать софт, чтобы ему хватало и более медленных процессоров.
> Пришло время переписывать софт на C, чтобы ему хватало и более медленных процессоров.Поправил.
Тогда дыры в процессорах никому не нужны будут.
Потому что можно взять много процессоров.
Пришло время использовать нормальный язык с созданный под него нормальный проц.
(* Нет не Си, не Раст, не питон *)Поправил.
Не дождётесь. Мы лучше будем пускать виртуалку в виртуалке - в виртуалке - ... - на большом кластере из простых ядер (без спекулятитвов), чтобы усложнить жизнь сторонним каналам.
И чтобы алгоритмы выполнялись за фиксированное время.
ОС РВ открыли
Моей заслуги тут нет, это всё специалисты АМД:
> компания AMD рекомендовала разработчикам использовать алгоритмы, математические вычисления в которых всегда выполняются за постоянное время, не зависимо от характера обрабатываемых данных
Там про уложиться в таймслот _сверху_.
А тут -- про и сверху, и снизу.
Снизу можно добавить недостающей паузы.
"Для определения ключа потребовалось выполнить 50500 трассировок. Общее время атаки заняло 38 минут."
В лабораторных условиях без сторонней нагрузки. Расходимся, интел-фанбои опять облажались.
Меня только одно напрягает: сейчас в ведро опять каких-нибудь заляпок насуют. Включение mitigations=off уже стало насущной необходимостью, а по мере увеличения количества заляпок видимо придётся штатные ядра из дистров перебирать с правкой конфига, потому что чеки всех этих заляпок тоже не бесплатные.
Не используйте забугорные изделия. Ни процы, ни тем более шиндошс.
И не помогут тебе, сынок, ни раст, ни карбон, ни даже эльбрус! Только святой 486 с влб шиной, только хардкор!
VLB защиты от утечек в проце не добавляет, поэтоту можно PCI-E. А ядра CPU можно и попроще, чем 486, но побольше количеством.
И "солярку" (в девичестве SunOS) взад вернуть. Она как раз под такой кейс была заточена. "Но что-то пошло не так."
Вы только что придумали графический ускоритель. Круг задач решаемый которым весьма ограничен.
ну вот как раз Эльбрус возможно и поможет..
Только ты его не купишь, ахахаха (с)
Почему?http://imaxai.ru -- материнки (внимание, 8С весьма придирчив по части DDR3)
http://bitblaze.ru -- системыКому много -- http://norsi-trans.ru
PS: моя домашняя машинка, если что -- "Эльбрус-16С".
PPS: есть тут нынче линуксоводы из .kz? :) (про давнего оппонента помню, но его почерк давно уж не примечал так чтоб явно)
Такое старьё я бы даже при наличии лишних денег не стал покупать. Что там слышно про 32с? Всё заглохло?
Материнская плата E8C-mITX на базе Эльбрус-8С и 2D-видео
Самая доступная плата на Эльбрус-8С
254 500 ₽Я что-то ржал
За 250к собирается 5950x c 128Гб ram и nvme рейдом. Вместе с коропусом, бп и охлаждением.
САМАЯ ДОСТУПНАЯ ПАЛАТА
Нет. Для дома такое не купишь. Даже с моей зарплатой."Купить" -- означает придёшь в каждый второй магазин и там оно лежит в свободной продаже по конкурентной цене. Даже с падением производительности в 10 раз -- в целях безопасности я готов купить. Но безопасность сомнительна, цена конская, куча других компонентов ,которые никак не гарантируют безопасность.
Увы, но это полумера.
как только zen 4 вышел, сразу в первых трёх поколениях уязвимость нашли, ага
Про уязвимости процессоров знает очень мало покупателей. Для кого эта информация? Явно не для них.
Мракетинг поможет им узнать ;)
Что говорит, что в zen 4 они скорее всего тоже есть, но исследователи не успели его купить, чтобы проверить.
Эти дыры уже перешли в категорию хакера и солонки.
Только это не солонка, а проц.
Солонка то, поопаснее будет...
Сравнения некоректны!
А выдавать соль и перец нужно в отдельных бумажных пакетиках, как это и делают в общепите.
> Сравнения некоректны!
> А выдавать соль и перец нужно в отдельных бумажных пакетиках, как это
> и делают в общепите.в общепите( те же столовые ) очень даже и солонки и перечницы стоят. Если повезёт - так и бутылки с соевым соусом и кетчупом на столе будут стоять
А как там поживают K10, Bulldozer и Pile-Driver? Не тестировали?
Мне показалось, или бОльшую часть процессорных уязвимостей находят в европейских университетах? То ли у них требования к безопасности выше, то ли заняться нечем.
в американских тоже. прям завидую такой системе образования, хотел бы там учиться. в MIT в каком-нибудь
> Мне показалось, или бОльшую часть процессорных уязвимостей находят в европейских университетах? То ли у них требования к безопасности выше, то ли заняться нечем.У них скорее больше свободы этим заниматься и открыто публиковать результаты. В РФ, к примеру, подобными исследованиями независимо заниматься фактически невозможно вообще. На всем, что с безопасностью связано сплошной интерес фсб.
В других местах такие уязвимости секретят и используют в своих целях. А в европейский спецслужбам такое нафиг не надо. Ну серьёзно ты считаешь что Австрия решила стать мировым гигемоном? Да там и спецслужбы то для вида существуют. Вот и выкладывают уязвимости в открытый доступ.И ещё кстати это маркер что уязвимости такие простые что из может обнаружить простой студент!
> Мне показалось, или бОльшую часть процессорных уязвимостей находят в европейских университетах?
> То ли у них требования к безопасности выше, то ли заняться
> нечем.Не показалось. Америка пытается продавать себя как может. А публикуя каждый месяц сообщения о проблемах в железе -- лохов не разведёшь.
Не находят, им говорят когда оглашать нужную инфу
>Процессоры Intel атаке не подвержены, так как в них используется одна очередь планировщика,а я всегда знал, что интел однозадачный
https://avatars.mds.yandex.net/get-mpic/5418200/img_id641869...
Не подключайтесь к сети, пишите всё ПО сами, включая ОС и компиляторы, и никто вас не взломает.
Это сложновато, даже TempleOS запускалась в виртуальной машине на убунту, что уж говорить об не особо энергичных людях.
Да он псих был.
> Не подключайтесь к сети, пишите всё ПО сами, включая ОС и компиляторы,
> и никто вас не взломает.В твоих словах анон нет логики. Самое главное забыл -- железо. А если железо, ПО, включая оС и компиляторы -- своё -- тогда зачем отключаться?...
> компания AMD рекомендовала разработчикам использовать алгоритмы, математические вычисления в которых всегда выполняются за постоянное время, не зависимо от характера обрабатываемых данных, а также избегать ветвления на основе секретных данныхГодный совет безотносительно утечек.
Чем он годный-то? Фиксированное время выполнения может упростить тайминг-атаку на кеши например.
Самый годный вариант - это алгоритмы с независимым от данных (псевдо)случайным временем выполнения, т.е. разбавленный небольшими рандомными (желательно с софт-независимой энтропией) задержками. Из этого что-то выцарапать будет совсем сложно.
А работать будет совсем медленно.
С чего бы.
Наши любимые "сторонние каналы" базируются на измерении либо времени работы критичного участка алгоритма, либо (если мы о всяких атаках на кеши) - время обращения к памяти, пытаясь определить, попали мы пальцем в ж..., простите, в кеш, или в память.
В первом случае всё потяжелее - нам надо рандом, сопоставимый с временем выполнения алгоритма. Т.е. в худшем случае мы это время удваиваем. Во втором всё просто. Шум, сопоставимый с 1-2 обращениями к памяти, сводит любые попытки это померить на нет.
> разбавленный небольшими рандомнымиСудя по твоим комментам здесь, ты считаешь рандом способом уберечься от измерений. Но это же бред. Зырь сюда:
double gauss_random(double mean, double variance) {
double a = drand48(), b = drand48();
return sqrt(-2 * log(a)) * cos(2 * M_PI * b);
}double add_noise(double secret, double variance) {
return secret + gauss_random(0, variance);
}int main() {
#define LEN 4
double secrets[LEN] = {0.42, -0.15, 0.18, 0.99}; // впиши сюда любые числа в диапазоне -1..1;
// lets take N samples of secrets with added noise
int N = 100;
double sum[LEN] = { 0.0 };
for(int i = 0; i < N; i ++) {
for(int j = 0; j < LEN; j++) {
// Notice this: noise variance is larger than a signal by an order of magnitude
sum[j] += add_noise(secrets[j], 10);
}
}
double rebuilt_secrets[LEN];
for(int i = 0; i < LEN; i++) {
rebuilt_secrets[i] = sum[i] / N;
}
// выведи здесь красиво табличкой secrets, rebuilt_secrets и разницу между ними
}Попробуй поменять N и посмотреть как при увеличении N растёт точность восстановления secret'а. Попробуй например выставить N=500 или 1000. Твой случайный шум -- это помеха, которая конечно же мешает атакующему, но не отменяет возможность атаки. Как мёртвому припарки.
Если твоя хомячья сущность требует комментировать разговоры умных дядей и сходу предлагать простое решение, которое конечно же всех спасёт, и о котором умные дяди почему-то молчат, то тебе нужен не случайный шум, а одно из этого:
1. надо отменить мораторий на смертную казнь (универсальный вариант, работает всегда)
2. задницу подрастающим поколениям драть, как нам драли (этот похуже, но как правило работает)
3. надо запретить шедулеру шедулить разные процессы на одно ядро.Но с 3 надо быть осторожнее. Любое отклонение от классических 1 и 2 требует осторожности. Это не так просто как кажется, потому что у шедулера нет времени пускать слюни и думать что и куда шедулить, да ещё и один новый эдж-кейс обрабатывать, когда есть свободные логические процессоры, есть простаивающие процессы готовые их утилизировать, но надо всё оставить как есть. Теоретически можно отбрыкаться от излишне умных, аппелируя к теоретической возможности придумать какой-нибудь резкий алгоритм, который так сделает. Но несмотря на недостатки у 3 есть бонус: твоя _целевая_ аудитория не поймёт о чём речь.
Ты путаешь тёплое с мягким.
Если у тебя уровень шума начинает превышать уровень полезного сигнала - всё, ничего ты уже не восстановишь, если не используешь шумоспецифичный фильтр. Который в случае рандома с примесью допустим хардварной энтропии не вырисовывается.
> Если у тебя уровень шума начинает превышать уровень полезного сигналаВ моём примере превышает, и это не мешает.
> шумоспецифичный фильтр
Я намеренно генерацию рандома с нормальным распределением выделил в отдельную функцию. Попробуй воткнуть туда что-нибудь другое. Единственное усложнение, с которым тебе придётся столкнуться, это вычисление среднего значения шума. То есть такого m, что если x_n рандомное число, то \sum (x_n-m) будет сходиться по вероятности к нулю, при n стремящимся к бесконечности.
> Который в случае рандома с примесью допустим хардварной энтропии не вырисовывается.
Прекрати поклоняться ложным идолам. Рандом -- не Бог, он не всемогущ. Он подчиняется статистическим закономерностям, типа закона больших чисел.
И заметь, что ты работаешь не с изменённым исходным сигналом, а пытаешься восстановить сигнал по косвенным факторам, что в корне отличается от приведённого тобой примера, где сигнал модулирован.
И что математический аппарат то и там и там одинаковый.
Угу. Только потребность в N различается на порядок порядков, а так ничего.
Ну и предлагаю подумать вот на какую тему: с фига ли эти "эксплоиты" работают с 50500 раза, и только в лабораторных условиях, без стороннего шума, если всё так легко восстанавливается усреднением? А вот с того фига так и работает, что малейший лишний шум, и всё.
И да, я не заметил, но с хера ли там шум аж строгого гауссового распределения будет?
Короче опять какие-то далёкие от реальности отмашки.
Чёт меня реально подгорело с этого маразма.
Гауссово распределение тем и хорошо, что оно сферическое в вакууме, и на каждый +x найдётся -x, соответственно чем больше N, тем больше шанс полной компенсации и меньше остаток.
В реальном же аппаратном шуме ты всегда получишь некоторый офсет, который в случае попытки замерить не известных характеристик сигнал тебе компенсировать абсолютно нечем. И потенциальный офсет замерить тоже нечем.
Впрочем, даже если это откинуть - при превышающем уровень сигнала шуме тебе надо будет огроменные N, чтобы этот шум компенсировать, и все эксплоиты потребуют огромного времени для получения более-менее достоверного байта информации, чего уже вполне достаточно.
> Чёт меня реально подгорело с этого маразма.Я тоже хотел это сказать, но ты раньше успел.
> при превышающем уровень сигнала шуме тебе надо будет огроменные N, чтобы этот шум компенсировать
Да, это практическая проблема. Но, во-первых, у обороняющегося от атак тоже будут огромные практические проблемы сделать шум достаточно большим -- он совершенно не хочет, например, варьировать частоту проца в два раза (процентов на 10 может и ок, но не в 2 раза), и он совешенно не хочет делать таймер неюзабельным настолько, что мультимедиа приложения пойдут лесом, или что профайлеры станут бесполезными. Во-вторых, разница во времени выполнения разных ветвей измеряемого алгоритма может исчисляться хоть часами -- откуда ты знаешь? Ты можешь как-то ограничить это время и сказать, что эта разница будет не больше \delta, указав конкретное значение этой \delta?
А, в-третьих, атаки бывают разными. Если в сервер впихнули код, который будет крутиться там годами, высчитывая ключ, то тебе этот N не поможет.
Зашумлять сигнал -- это усложнять жизнь атакующему. Атака остаётся теоретически возможной, и про реальную систему во всей её сложности ты никогда не сможешь доказать, что она невозможна практически. Fail.
перешел по ссылке на оригинал https://stefangast.eu/papers/squip.pdf
VMware вообще нет, хотя это большая часть в Enterprise, в References есть Xen и Hyper-V, Xen даже вскользь в теле статьи (cross-VM: KVM/Xen doesn't support rdpru) - и совершенно непонятно в итоге, кроме как между KVM виртуалками этот эксплойт применим вообще?
В EPYC насколько мне известно есть аппаратное шифрование памяти AES, что по идее не может давать считать данные в открытую по стороним каналам?! Или в новости EPYC указан просто так и на этих процах не проводилась атака?
Предположу, зашифрованные они только в памяти. Не могут же зашифрованные данные находиться в планировщике - с такими данными нельзя работать.
Когда содержимое памяти попало в кеш или в какие промежуточные регистры в ЦПУ, оно там расшифровано.
Предположу, что в L3 & L2 зашифрованный данные попасть могут. Насчёт L1 - скорее всего, тоже. Речь ведь не о кеше микроопераций, а данных.
> В EPYC насколько мне известно есть аппаратное шифрование памяти AES, что по
> идее не может давать считать данные в открытую по стороним каналам?!
> Или в новости EPYC указан просто так и на этих процах
> не проводилась атака?Если данные ВСЕГДА зашифрованы -- как их тогда использовать?
Процессор не умеет работать с зашифрованными данными (и кеш тоже). Для этого надо такой огород городить, что площадь кристалла раздует кратно. И всё-равно будет фаза расшифрованных данных.Вопрос решается по другому: своя гарантированно надёжная, изолированная, тупая железка. Которые свои ключи не отдаёт никогда и никому.