уязвимости
В середине июля исследователи из Швейцарской высшей технической школы Цюриха опубликовали свежее исследование, в котором описали новую атаку с использованием уязвимостей (или, если хотите, особенностей) современных процессоров. Атака получила название Retbleed, которое происходит от Retpoline — так именуют метод защиты от определенного типа атак семейства Spectre. По сути авторы работы показали, что способ компиляции программ, считавшийся ранее эффективной защитой их от атаки Spectre так называемого «второго варианта», на самом деле не работает или работает далеко не всегда. Исследование, как и все предыдущие работы об аппаратных уязвимостях в процессорах, сложное. В этой статье мы, по традиции, постараемся не забираться глубоко в дебри научных работ и попробуем описать результаты простыми словами. А начнем с небольшой предыстории.
Что такое Spectre v2? Поговорим о предсказании ветвлений
Две научные работы, описывающие уязвимости Spectre и Meltdown, были опубликованы в начале 2018 года, больше четырех лет назад. Это аппаратные уязвимости — потенциальная атака с кражей данных стала возможной благодаря особенностям работы процессоров. С тех пор было обнаружено еще несколько вариантов Spectre: исследователи находили все новые способы атаковать один общий класс уязвимостей, а конкретно — использовать для атаки штатную функциональность процессора под названием «предсказание ветвлений» или «branch prediction».
Предсказание ветвлений и спекулятивное выполнение инструкций помогает серьезно повысить производительность процессора. В любой программе выполнение дальнейших шагов часто зависит от результата предыдущих вычислений. Простейший пример: пользователь вводит пароль для доступа к каким-то секретным данным. Если пароль правильный, мы показываем пользователю данные. Если неправильный — просим ввести пароль еще раз. На уровне простейших инструкций, которые обрабатывает процессор, это транслируется, скажем, в проверку прав доступа к определенным данным в оперативной памяти: если права есть, можно прочитать данные, если нет — нельзя.
Процессор может выполнять миллиарды таких операций в секунду и, пока проверяется определенное условие, часто простаивает (условно — ждет, пока пользователь введет пароль или закончится проверка прав доступа). Что, если заранее выполнить вычисления, которые произойдут после наиболее вероятного результата проверки определенного условия? К моменту, когда гипотетический пользователь введет гипотетический пароль, результат вычислений уже будет готов, и мы покажем пользователю его секрет немного быстрее.
А как понять, какая часть кода будет выполнена с наибольшей вероятностью? По статистике предыдущих выполнений подобных инструкций, конечно же. Если условный пользователь (внимание, это очень теоретический и крайне упрощенный пример) в 9 случаев из 10 вводит правильный пароль, то можно заранее подготовить его секретные данные. Если пароль неправильный — ну и ладно, отбросим результаты работы и чуть дольше будем выводить сообщение об ошибке.
Авторы работы 2018 года описали два варианта атаки Spectre, и второй вариант (также известный как Branch Target Injection) тренирует предсказатель ветвлений так, чтобы он выполнял нужные нам инструкции — читал данные, к которым атакующий не должен иметь доступ. Да, эти вычисления потом отбрасываются, но их результат (те самые секретные данные) некоторое время сохраняется в кэш-памяти, откуда их можно похитить.
Это крайне сложная атака. Во-первых, для ее реализации требуется иметь возможность выполнения кода на атакуемой системе, пусть и без нужных нам привилегий, то есть без доступа к секретным данным. Например, можно заставить пользователя открыть веб-страницу с вредоносным скриптом в браузере. Во-вторых, требуется работающее на атакуемой системе ПО, в котором есть пригодный для проведения атаки код: на сленге исследователей он называется «гаджетом». Атакующий код тренирует систему предсказания ветвлений так, чтобы произошло спекулятивное выполнение «гаджета». Это приводит к обращению к недоступной для атакующего области памяти. Секретные данные помещаются в кэш-память процессора, откуда очень медленно (со скоростью в единицы или десятки бит в секунду) эти данные можно извлечь с помощью так называемого метода чтения по сторонним каналам.
Попробуем еще проще. Встроенная в процессор система предсказания ветвлений не разделяет инструкции разных программ, и с помощью одной программы можно заставить процессор спекулятивно выполнить инструкцию, которую он не должен выполнять. Раньше это не казалось проблемой: данные в кэш-памяти процессора все равно недоступны программам напрямую. Но, как оказалось, с помощью чтения по сторонним каналам (это очень сложный механизм, реконструирующий данные только на основе информации о скорости ответов на запросы чтения) данные можно вытащить.
Подождите, но Spectre обнаружили в 2018 году. И уже, наверное, закрыли?
С аппаратными уязвимостями все не так просто. Во-первых, даже из нашего упрощенного описания видно, что уязвимость, конечно, аппаратная, но для ее работы требуется определенное совпадение условий в программном обеспечении. А если так, почему бы просто не пропатчить ПО? Тем более, что сделать это гораздо проще, чем обновить железо. Частично можно исправить уязвимость и в процессоре, обновив его так называемый «микрокод». Но радикально решить проблему получится только путем выпуска новых процессоров с измененной «железной» частью. А старые тем временем так и останутся полностью или частично уязвимыми.
Есть еще один вопрос, который крайне важен в контексте исследования Retbleed. Какова будет стоимость программной или аппаратной заплатки? Абсолютно все способы «закрытия» Spectre снижают производительность. Например, достаточно очевидная система Indirect Branch Restricted Speculation вводит дополнительную проверку прав при спекулятивном выполнении кода и не позволяет программам с низкими привилегиями обращаться к особо секретным данным, делая атаку Spectre невозможной. Но при масштабе в сотни тысяч и миллионы подобных проверок обязательно снизится производительность процессора. На сколько? Есть исследование, показывающее падение производительности до 25% в результате включения разнообразного набора патчей для Spectre.
И тут на сцену выходит Retpoline: предложенный инженерами Google относительно простой метод защиты от Spectre, применяемый при компиляции программ. Замена одних инструкций в типичных ситуациях ветвления на другие не влияет на работоспособность ПО, но, как предполагали авторы метода, делает невозможной атаку Spectre. Важное преимущество Retpoline перед IBRS и другими методами защиты заключается именно в небольшом падении производительности — не более 5% от «номинальной».
Что показало исследование Retbleed?
Точно, мы же про Retbleed рассказываем! Свежая исследовательская работа показала, что Retpoline не работает. Так называемые инструкции возврата, на которые полагался метод Retpoline, также могут эксплуатироваться в слегка видоизмененной схеме «обмана (или вредоносной тренировки) предсказателя ветвлений». Авторы работы даже записали видео с демонстрацией атаки:
Демонстрация атаки Retbleed в системе на базе Linux.
На видео показана кража хэшированного пароля суперпользователя программой, которая не имеет доступа к этим данным. Обратите внимание, что видео сильно ускорено: в реальном времени кража пароля занимает на системе с процессором Intel больше полутора часов! Результаты работы сведены в общую таблицу:
Сводный список процессоров, протестированных на возможность атаки Retbleed с активированной защитой Retpoline. Источник
Как видно из таблицы, атаке Retbleed подвержены не новые, но вполне актуальные процессоры AMD с архитектурой Zen 1 и Zen 2 (2017–2019 годов выпуска) и процессоры Intel поколения Kaby Lake и Coffee Lake (2016–2017). Для более современных процессоров AMD Zen 3, а также для Intel Alder Lake и более ранних процессоров девятого поколения атака Retbleed не работает. В том числе благодаря внедрению аппаратной защиты Enhanced IBRS в процессорах Intel.
Стоимость защиты
Если атака Spectre такая сложная, зачем вообще от нее защищаться? Действительно, для того чтобы приспособить Spectre к какому-то реальному делу (с реальным ущербом для жертвы), нужно соблюсти очень много условий: иметь возможность выполнять код на атакуемой системе, иметь подверженное атаке установленное ПО, надежно вытаскивать данные из кэш-памяти (с определенным шансом на чтение с ошибками). Ранее мы писали, что самая реалистичная атака была смоделирована в браузере Chrome, где потенциальный злоумышленник мог «вытаскивать» из оперативной памяти, например, сохраненные пароли. Но и она решилась простым усилением защиты в самом браузере, как любой другой, более тривиальный баг.
Есть некоторая вероятность, что постепенный прогресс в исследовании Spectre-подобных уязвимостей неожиданно приведет к возможности массовой атаки на компьютеры пользователей и серверы. Но когда речь идет о действительно секретных данных, Spectre надо принимать во внимание уже сейчас.
Самый очевидный сценарий — это атака через поставщиков услуг хостинга и распределенных вычислений. Типичный виртуальный сервер, который вы можете арендовать за небольшую сумму у понравившегося провайдера — это, по сути, программа, которая выполняется по соседству с такими же виртуальными ОС других клиентов на одном мощном сервере. Арендатор виртуального сервера по определению может выполнять на нем программы, но не имеет привилегий для доступа к соседям или к «хосту», то есть к управляющей операционной системе. Разделение виртуальных сред и невозможность «побега» из своего виртуального окружения — ключевое требование безопасности для поставщиков подобных услуг.
Провайдеры услуг заинтересованы и в том, чтобы на одном сервере без проблем друг для друга работало как можно больше виртуальных систем — это залог скорейшей окупаемости затрат на дорогое железо. При этом все заплатки для Spectre (которые реально работают) снижают производительность, а значит, уменьшают доход провайдера. Но и игнорировать проблему нельзя, ведь успешная кража секретных данных даже не оставляет следов!
Поэтому, когда был предложен Retpoline, многие схватились за него как за чудо-соломинку для борьбы с новой напастью. Но уже в январе 2018 звучали сомнения в том, насколько этот метод борьбы надежен. В этом обсуждении в листе рассылки разработчиков ядра Linux приводится ряд претензий к Retpoline (о других методах автор тоже отзывается нелестно). Тогда же Линус Торвальдс, создатель и главный хранитель Linux, высказался (в достаточно характерной для него резкой манере) о том, что Retpoline в целом достаточно.
Авторы Retbleed припомнили Торвальдсу его категоричность, поместив его безапелляционную цитату в начало работы. Там же они рассчитали «цену» реально работающей защиты для уязвимых процессоров, которые аппаратно уже не исправить. Исправления в ядре Linux привели к падению производительности до 39% для процессоров Intel и до 14% для процессоров AMD.
Ну и последний важный вывод из исследования Retbleed: процессоры AMD оказались уязвимы по-своему, и в них авторы обнаружили явление, которое назвали Phantom JMPs. Оказалось, что при некоторых условиях можно заставить систему предсказания ветвлений выполнить произвольную инструкцию, даже если в атакуемом коде ее нет. Из-за этого к исследованию пришлось выпустить краткое одностраничное дополнение. Там же авторы оговариваются, что эксплуатировать эту уязвимость для нанесения реального вреда еще сложнее, чем традиционный Spectre v2.
И что теперь делать?
Для обычных пользователей угроза атак Spectre остается совершенно виртуальной. Достаточно превентивных заплаток, которые будут готовить разработчики операционных систем. В ОС Windows, кстати, эффективный метод защиты IBRS включен по умолчанию. Новые патчи ядра Linux, возможно, приведут к снижению производительности, что может быть наиболее заметно в бизнес-решениях, где из компьютерного железа выжимают всю возможную мощность.
Проблема осложняется тем, что вариантов Spectre много. Retbleed тоже можно считать таким отдельным вариантом, который еще и по-разному работает на процессорах разных производителей. Компании AMD и Intel признали Retbleed как отдельную уязвимость и, возможно, придумают какое-то аппаратное решение для нее. Корпорации перейдут на новое железо, в котором эти системы защиты будут внедрены, и найдут баланс между производительностью и безопасностью. К сожалению, все программные заплатки больше всего сказываются на производительности в относительно старых процессорах. Мало того, что программы со временем становятся «тяжелее», так тут еще и этот «налог» на спекулятивное выполнение.
Если посмотреть на проблему с высоты птичьего полета, в ней нет ничего нового. Разработчики предлагают какое-то решение, повышающее производительность, но не думают о безопасности. Рано или поздно (в данном случае поздно: спекулятивное выполнение начали применять в середине девяностых) это выходит боком, за дополнительную защиту приходится расплачиваться всем, но со временем находятся новые решения, и индустрия высоких технологий движется дальше.
Неожиданностью стало обнаружение проблемы в железе: ее не так просто исправить, как в софте. И это не простая ошибка, а, скорее, не совсем удачные с точки зрения безопасности подходы, принятые в индустрии много лет назад. Будем надеяться, что разработчики процессоров придумают новые методы безопасных и производительных вычислений до того, как над нами пролетит черный лебедь крайне опасной атаки на железо, которая угрожает всем, известна публично и решается только тотальной заменой парка техники на новую.
Советы