[Перевод] Почему открытые прошивки важны для безопасности11.05.2019 13:47

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

Уровни привилегий

В типичном стеке у вас различные уровни привилегий.

• Кольцо 3. Приложения:  минимальное привилегий, за исключением песочницы в пользовательском пространстве, которая ещё больше ограничена.
  
• Кольцо 0. Ядро:  ядро операционной системы, в случае ОС с открытым исходным кодом вы видите его код.
  
• Кольцо −1. Гипервизор:  мониторинг виртуальных машин (VMM), создаёт и запускает виртуальные машины. В гипервизорах с открытым исходным кодом, таких как Xen, KVM, bhyve и другие, вы видите код.
  
• Кольцо −2. Режим управления системой (SMM), ядро UEFI: проприетарный код, подробнее об этом ниже.
  
• Кольцо −3. Движок управления:  проприетарный код, подробнее об этом ниже.

Отрицательные кольца указывают на уровни с привилегиями больше, чем у нулевого.
Из вышесказанного ясно, что в кольцах от −1 до 3 у нас есть возможность использовать программное обеспечение с открытым исходным кодом, в значительной степени видеть и контролировать его. Для уровней ниже кольца −1 у нас меньше контроля, но ситуация улучшается благодаря разработке open source прошивок и сообществу.

Это противоречивая ситуация: у самого закрытого кода больше всего привилегий в нашей системе. Данный парадокс должны исправить прошивки с открытым исходным кодом.

Кольцо −2. SMM, ядро UEFI

Это кольцо управляет всеми ресурсами CPU.

Режим управления системой (SMM) невидим для остальной части стека поверх него. У него половина ядра. Первоначально использовался для управления питанием и аппаратного управления системой. Он содержит много проприетарного кода и является тем местом, куда поставщики добавляют новые проприетарные функции. Он обрабатывает системные события, такие как ошибки памяти или чипсета, а также кучу другой логики.

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

Кольцо −3. Движок управления

Самое привилегированное кольцо. В случае Intel (x86) это Intel Management Engine. Эта система может незаметно включать узлы и перезаписывать диски, ядро запускает Minix 3, а также веб-сервер и весь сетевой стек. Получается, что благодаря этому Minix — самая популярная операционная система на десктопах. В движке управления много функций. Вероятно, мне потребуется целый день, чтобы перечислить их. Если хотите, есть многоресурсов для более подробного изучения.

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

У них всех есть эксплоиты

Никого не должно удивлять, что в кольцах −2 и −3 есть уязвимости. Когда их находят, это действительно ужасно. Просто для примера, хотя вы можете поискать и другие примеры самостоятельно, но в веб-сервере Intel Management Engine был баг, о котором разработчик не знал семь лет.

Как можно улучшить ситуацию?

NERF: нерасширяемая уменьшенная прошивка

NERF — это то, над чем работает сообщество. Цель состоит в том, чтобы сделать прошивку менее способной причинить вред и сделать её действия более заметными. Они стремятся удалить все компоненты среды выполнения, но пока в Intel Management Engine это трудно сделать. Зато можно убрать оттуда веб-сервер и IP-стек. Разработчики также хотят удалить IP-стек UEFI, другие драйверы и убрать функцию самопрошивки Intel Management/UEFI.

me_cleaner

Проект для очистки Intel Management Engine до минимально необходимой функциональности (на GitHub).

u-boot и coreboot

u-boot и coreboot — прошивки с открытым исходным кодом. Они обрабатывают инициализацию микросхем и DRAM. В хромбуках используются обе, coreboot на x86, а u-boot на остальных. Это один из этапов, как они проверяют загрузку.

Философия дизайна Coreboot заключается в том, чтобы «сделать минимум, необходимый для использования оборудования, а затем передать управление другой программе, которая называется полезной нагрузкой». В данном случае это linuxboot.

linuxboot

Linuxboot обрабатывает драйверы устройств, сетевой стек и предоставляет многопользовательскую многозадачную среду. Он построен на Linux, так что одно ядро может работать на нескольких платах. Linux уже достаточно проверен и за кодом многие следят, так как он довольно широко используется. Лучше использовать открытое ядро с большим числом «контролёров», чем два с половиной других ядра, разные и закрытые. Это означает, что мы уменьшаем поверхность атаки за счёт меньшего количества вариантов кода и полагаемся на открытый исходный код. Linux повышает надёжность загрузки, заменяя слабо протестированные драйверы прошивки драйверами Linux с усиленной защитой.

Используя ядро, у нас уже есть инструменты для прошивки: разработчики могут использовать знакомые инструменты, когда нужно написать логику для проверки подписи, шифрования диска и так далее. Всё это на современном, проверенном, поддерживаемом и легко читаемом языке.

u-root

u-root — это набор инструментов golang userspace и загрузчик. Он используется как initramfs для ядра Linux в linuxboot.

Говорят, стек NERF уменьшил время загрузки в 20 раз. Но это статья по безопасности, так что давайте вернёмся к безопасности…

Стек NERF улучшает видимость многих компонентов, которые ранее были совсем проприетарными. Однако на устройствах остаётся ещё много других прошивок.

Что насчёт других прошивок?

Нам нужны открытые прошивки для контроллера сетевого интерфейса (NIC), твёрдотельных накопителей (SSD) и базового контроллера управления (BMC).

В проекте Open Compute ведётся определённая работа над на прошивкой NIC 3.0. Будет интересно посмотреть, что у них получится.

Для BMC есть как OpenBMC, так и u-bmc. Я немного писала о них в предыдущей статье.

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

Корни доверия

Цель корня доверия заключается в проверке, что в каждом компоненте оборудования установлено соответствующее программное обеспечение. Вы можете гарантированно убедиться, что оборудование не взломано. Поскольку сейчас у нас очень много закрытого кода на многих участках оборудования, это трудно сделать. Как реально узнать, что в прошивке компонента нет уязвимостей или бэкдоров? Никак. Другое дело с открытым исходным кодом.

Похоже, каждое облако и каждый вендор предлагают собственный корень доверия. У Microsoft есть Cerberus, у Google — Titan, у Amazon — Nitro. Похоже, они предполагают явное доверие к проприетарному коду (код, который мы не видим). Это оставляет странное ощущение. Не лучше ли было использовать полностью открытый код? Тогда мы можем без сомнений проверить, что собранный из исходников код — тот же самый, который работает на оборудовании везде, где установлена прошивка. Затем мы можем проверить, что машина находится в правильном состоянии, не сомневаясь, что она уязвима или с бэкдором.

Это заставляет задуматься, что же используют в качестве корня доверия небольшие облачные провайдеры, такие как DigitalOcean или Packet. Я спросила об этом в Twitter, но не получила достойного ответа…

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

Все облачные провайдеры должны убедиться, что оборудование не скомпрометировано после выполнения клиентом вычислений на нём.

Отказоустойчивость прошивки платформы

Однако у производителей микросхем, похоже, особый взгляд. У Intel есть технология отказоустойчивости платформы Platform Firmware Resilience, а у Lattice — Platform Firmware Resiliency. Они, похоже, больше сосредоточены на руководящих принципах NIST по отказоустойчивости прошивки платформы.

Я попыталась спросить в интернете, кто это использовал, но получила мало откликов, поэтому, если вы используете устройства с технологией Platform Firmware Resiliency, дайте мне знать!

Из лекции OCP об инновациях в прошивках Intel кажется, что Platform Firmware Resilience (PFR) от Intel и Cerberus идут рука об руку. Корпорация Intel использует PFR для воплощения принципов аттестации Cerberus. Спасибо @msw за разъяснение.

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

Как помочь

Надеюсь, вы получили некоторое представление о том, какие проекты существуют для разработки прошивок с открытым исходным кодом и насколько это важно! Если хотите помочь, пожалуйста, расскажите другим. Попробуйте использовать платформы с открытыми компонентами. Хромбуки — отличный пример, а также компьютеры Purism. Можете спросить своих поставщиков, что они делают для выпуска прошивки с открытым исходным кодом и обеспечения безопасности оборудования с корнями доверия. Счастливого ботана! :)

© Habrahabr.ru