LINUX.ORG.RU

Найдена и исправлена ошибка в ядре Linux, позволявшая эксплуатировать уязвимость Spectre

 , ,


0

1

13 апреля Эдуардо Вела Нава, специалист из группы реагирования на безопасность продуктов Google, сообщил о новой уязвимости в ядре Linux 6.2, связанной с принципом работы уязвимости Spectre. О недостатке безопасности средней степени 31 декабря 2022 года специалисты сообщили в первую очередь поставщикам облачных услуг. 27 февраля 2023 года уязвимость уже была исправлена.

«Ядро не могло защитить приложения от Spectre v2, оставляя их открытыми для атак со стороны других процессов, работающих на другом гиперпотоке того же физического ядра», — поясняют специалисты. Следствием использования уязвимости является потенциальное раскрытие конфиденциальной информации.

Само название « Spectre » описывает целый набор уязвимостей, злоупотребляющих «спекулятивным выполнением» или оптимизацией производительности процессора, при которой потенциальные инструкции выполняются заранее для экономии времени.

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

Вскоре после первых попыток исправить ошибки Meltdown и Spectre, Intel опубликовала подробности об Indirect Branch Restricted Speculation (IBRS) — механизме ограничения спекуляций непрямых ветвей, которые сообщают процессорам о необходимости начать выполнение инструкций в новом месте.

IBRS предлагает защиту от Spectre v2 , которую Intel называет Branch Target Injection (BTI). Внедрение целевых ветвлений — это метод обучения предсказателей ветвлений спекулятивному выполнению определенных инструкций для вывода данных в кэш-памяти процессора с использованием побочного канала синхронизации.

IBRS поставляется в двух вариантах: базовом (устаревшем) и расширенном. И именно базовый вариант оказался уязвимым с точки зрения безопасности. Багхантеры, выявившие проблему, обнаружили, что процессы пользовательского пространства Linux для защиты от Spectre v2 не работают на виртуальных машинах «по крайней мере одного крупного облачного провайдера», название которого не уточняется.

Как сообщается в описании уязвимости, при базовой IBRS ядро ​​6.2 имело логику , которая отказывалась от STIBP (Single Thread Indirect Branch Predictors), защиты от совместного использования прогнозирования ветвлений между логическими процессорами на ядре.

«Бит IBRS неявно защищает от внедрения целевых ветвей между потоками. Однако в устаревшем IBRS бит сбрасывался при возврате в пользовательское пространство из-за соображений производительности, что отключало неявный STIBP и делало потоки пользовательского пространства уязвимыми для внедрения целевых ветвей между потоками, от которых STIBP обычно такую защиту обеспечивает», — поясняется в отчёте об уязвимости.

Исправление удалило базовые IBR из проверки spectre_v2_in_ibrs_mode(), чтобы сохранить STIBP включенным по умолчанию.

>>> Подробности



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 6)

Заголовок материала на securitylab доставляет, конечно, если внимательно прочитать сам материал и обнаружить, что заголовок к нему никакого отношения не имеет. :)

hobbit ★★★★★
()

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

firkax ★★★★★
()

Где там любители написать «Шеретооо!»? Алёё, просыпаемся, в прямом и переносном смысле.

iron ★★★★★
()
Ответ на: комментарий от hobbit

В такие ИБшные страшилки нужно обязательно добавлять абзац как отключить эти дополнительные тормоза.

slackwarrior ★★★★★
()

Как же было все просто, пока не было спекулятивного выполнения.

Хорошо ли это?

Не лучше делать просто больше ядер?

zx_gamer ★★★
()
Ответ на: комментарий от zx_gamer

Как же было все просто, пока не было спекулятивного выполнения.

А нельзя было, не знаю там, дополнительные кеш-линии ввести для спекулятивного исполнения, чтобы основные не аффектились? Ведь для регистров именно так и сделали: для спекуляций используются приватные регистры, которые потом меняются с настоящими, если спекуляция подтверждается. Почему нельзя с кеш-линиями тот же трюк провернуть? Вроде бы тогда все сайд-эффекты спекуляции пропадали бы бесследно…

anonmyous ★★
()

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

bernd ★★★★★
()
Ответ на: комментарий от thegoldone

Кэш – дорого.

А вот эти костыли все плодить в огромных количествах, и потом терпеть уязвимости уже в них самих - не дорого? :)

anonmyous ★★
()

Те ахуллиарды, которые тратят на безопасность, лучше бы потратили на разделение: процессор для работы, процессор для интернета. Или что-то в этом роде. Настольные компы не нужно перегружать защитой и сотнями тысяч заплаток и проверок. Это глупость. Настольным компам нужно максимальное быстродействие и минимум тактов на безопасность. Это очевидно. Кому нужен интернет для работы постоянно – вот путь они и страдают. Остальные-то при чём?

rechnick ★★★
()
Ответ на: комментарий от slackwarrior

Надеюсь, generic параметр mitigations=off ими не забыт.

Кто-нибудь живьем видел хоть одну атаку с использованием этих эксплоитов?

pekmop1024 ★★★★★
()
Ответ на: комментарий от token_polyak

Не знаю что такое сорта и экзабор, но в фотоаппаратах сделали именно подобное: матрица для съёмки отдельно, матрица для вывода экран (live view) отдельно. Чтобы основная не грелась и не шумела. Соломоново решение.

rechnick ★★★
()
Ответ на: комментарий от rechnick

матрица для съёмки отдельно, матрица для вывода экран (live view) отдельно

Откуда вы взяли этот бред? Точнее, в какой-то древней цифровой камере то ли от сони, то ли от олимпуса было что-то похожее, но ни во одной современной камере (т.е. за последние лет 10) такого нет. В зеркальных есть отдельный (от матрицы) фазовый датчик автофокуса и отдельный (на пентапризме) датчик экспозамера, но картинки для liveview они выдавать не могут. В беззеркалках - одна матрица на всё, больше ничего.

redeyedanonymous
()
Ответ на: комментарий от zx_gamer

Как же было все просто, пока не было спекулятивного выполнения. Хорошо ли это? Не лучше делать просто больше ядер?

Все это уже есть и реализованно!!!! Прямо сейчас в твоем компьютере находится такой вычислитель, называется GPU, там нет спекулятивного исполнения и очень много ядер.

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 2)
Ответ на: комментарий от Original_1

Мы у себя на работе целое исследование проводили, нашли только несколько нерабочих PoC-эксплоитов.

pekmop1024 ★★★★★
()
Ответ на: комментарий от hobbit

Теперь он не имеет отношения к реальности вообще.

Goury ★★★★★
()
Ответ на: комментарий от mandala

Не на столько много, чтобы переходить на амуде

Переходить надо было 20 лет назад, когда amd64 появилось.

firkax ★★★★★
()
Ответ на: комментарий от hobbit

Зря ты так. В заголовке по ссылке как раз правильно указано, что речь о баге в ядре, а этот копипастер, что запостил новость на лор, выдумал какую-то «новую уязвимость семейства spectre». Ну а взламывали там какого-нить облачного провайдера или нет - это уже нигде не уточняется. Может и правда взломали, но он пожелал остаться неизвестным.

Поясняю насчёт «бага в ядре»: баг в том, что там стояли затычки против spectre для ядерного кода, но для юзерспейса они отключались. Теперь они догадались что юзерспейс (разные процессы друг от друга, в т.ч. в разных виртуалках) тоже хорошо бы защищать. А уязвимость всё та же старая.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от bernd

ни разу, есть только симуляции в универах

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от rechnick

Так разделяй, кто не дает. Делаешь две виртуалки, в одну отдаешь одни ядра(вместе с логическими ядрами), в другую другие

cobold ★★★★★
()
Ответ на: комментарий от cobold

Ты правда не понял в чём фишка? Какой смысл разделять, если я получаю и систему и софт, в котором половина процессорного времени тратится на безопасность. И как я это разделю сейчас? Оно зашито намертво и каждый чих проверяется. Во всяком софте есть заплатки от внешних угроз. тысячи их. И они не бесплатные – на каждую процессор тратит ресурс. Это всё равно что на вредном производстве ходить в скафандре и дома тоже ходить в скафандре.

rechnick ★★★
()
Ответ на: комментарий от rechnick

Open Source, you know? Пересобираешь с отключенными заплатками и вперед

cobold ★★★★★
()
Ответ на: комментарий от anonmyous

Спекулятивное выполнение – экономия. Вместо нескольких ядер и систем вокруг них используется одно. Вы предлагаете экономию перебить отказом от неё.

thegoldone ★★
()
Ответ на: комментарий от anonmyous

А нельзя было, не знаю там, дополнительные кеш-линии ввести для спекулятивного исполнения, чтобы основные не аффектились?

Для того чтоб спектры не работали нужно либо не пытаться префетчить данные если на 100% не уверен что они реально понадобятся, либо, что предлагаешь ты, вводить искусственные задержки или просто отказываться от использования присутствующих в кэше данных в случае если они префетчнулись неправильно. Оба этих варианта просто дико неоптимальны.

С другой стороны, если брать простого человека, то проблема +/- решается просто отключением точного таймера в браузере, что вроде как уже сделали.

khrundel ★★★★
()
Ответ на: комментарий от thegoldone

Спекулятивное выполнение – экономия. Вместо нескольких ядер и систем вокруг них используется одно. Вы предлагаете экономию перебить отказом от неё.

Да ни в коем разе. Я предлагаю ввести доп кеш-линии, которые будут использоваться только при спекулятивном исполнении. А доступными для не-спекулятивных операций их данные будут становиться только если спекуляция подтвердилась.

Так сделано и с регистрами: спекуляция не аффектит видимые регистры, а работает с внутренними. Потом они, в случае успеха, подменяют видимые из-вне регистры.

anonmyous ★★
()
Ответ на: комментарий от khrundel

либо, что предлагаешь ты, вводить искусственные задержки

Вообще даже ничего подобного я не предлагал. Задержки - максимально тупейший и медленный костыль.

anonmyous ★★
()
Ответ на: комментарий от redeyedanonymous

В зеркальных есть отдельный (от матрицы) фазовый датчик автофокуса и отдельный (на пентапризме) датчик экспозамера

Вы не из нижегородской фирмы, которая OpenCV штатам продала?

i_am_not_ai
()
Ответ на: комментарий от Original_1

После каждой новости об уязвимости судорожно выдёргиваешь сетевые кабеля из локалхоста и ждёшь патча?

Logopeft ★★
()

Ко всем этим новостям об уязвимостях хорошо бы иметь оценку применимости решета. Подозреваю, что воспроизводится в очень особых условиях под свечкой из пингвиньего жира, скорость считывания памяти - мегабайт в 3 часа, и чудо, если в течение этого часа память не перезапишется 100 раз. Штеуд несёт репутационные потери, тратит время на фикс, теряет производительность, АМД довольны.

Logopeft ★★
()
Ответ на: комментарий от Logopeft

Такие уязвимости есть во всех процессорах, где спекулятивное выполнение есть. Амуде процессоры не подвержены только Meltdown’у

fancat
()
Ответ на: комментарий от ox55ff

АМД-бояре

…тоже подвержены Spectre, разве нет?

hobbit ★★★★★
()
Ответ на: комментарий от fancat

Амуде процессоры не подвержены только Meltdown’у

Увы, это оказалось не так. Изначально у них мельт, и правда, в архитектуру не заложен. Но они его добавили для совместимости, и назвали «Transient Execution of Non-canonical Accesses». Это ровно тот же мельт, только в явном виде, а не в виде результата неудачной оптимизации производительности.

anonmyous ★★
()
Ответ на: комментарий от anonmyous

То что ты предлагал ещё хуже.

В чём вообще проблема? Спекулятивно исполняющийся код запросил данные из памяти, они пришли, но код отменился и теперь, замеряя время доступа к памяти, программа может выяснить по какому адресу данные были запрошены. В 0.01% случаев. В остальных это будет вполне легитимное поведение, в if без else начали исполнять код после, а потом выяснилось что нужно всё-таки в блок нырнуть, но потом таки выполнить код после if. Твоё предложение - выкинуть эти уже полученные данные на помойку. Это решение, тогда новый запрос по этому же адресу займет много времени и злодей ничего не узнает. Но этого же эффекта можно добиться если просто вставить задержку. Тогда по крайней мере не придется второй раз эти же данные запрашивать и итак узкую шину загружать

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Твоё предложение - выкинуть эти уже полученные данные на помойку.

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

Тогда по крайней мере не придется второй раз эти же данные запрашивать и итак узкую шину загружать

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

anonmyous ★★
()

Покажите мне дурака, запускающего игрушку с торрента одновременно с браузером в котором интернет банк. Кроме @lenin386, тот и оффтопик жрет да похрюкивает

DumLemming ★★★
()
Ответ на: комментарий от pekmop1024

ИБшники еще и про битфлипы любят рассказывать. :) И про то что такие эксплойты стоят миллиарды и что тебе их никто не покажет.

А на деле все работают в конторах которые миллиард видели только во сне ее владельца. :)

mrdeath ★★★★★
()
Ответ на: комментарий от mandala

А почему бы и нет? Новая гонка частот это конечно здорово, но невозможно до бесконечности наращивать скорость 1 потока. Распаралеливание обходится дешевле.

kirill_rrr ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.