Микроархитектурная безопасность AWS Firecracker VMM: Аннотация и введение

Таблица ссылок

• Аннотация и введение
• Фон
• Модели угроз
• Анализ систем сдерживания фейерверков
• Анализ микроархитектурных атак и средств защиты в микроVM Firecracker
• Заключение, благодарности и ссылки

АБСТРАКТНЫЙ

Firecracker — это менеджер виртуальных машин (VMM), специально созданный Amazon Web Services (AWS) для бессерверных облачных платформ — сервисов, которые запускают код для конечных пользователей для каждой задачи и автоматически управляют серверной инфраструктурой. Firecracker предоставляет быстрые и легкие виртуальные машины и обещает сочетание скорости контейнеров, обычно используемых для изоляции небольших задач, и безопасности виртуальных машин, которые, как правило, обеспечивают большую изоляцию за счет производительности. Такое сочетание безопасности и эффективности, по утверждению AWS, делает не только возможным, но и безопасным выполнение тысяч пользовательских задач от разных пользователей на одном и том же оборудовании, при этом хост-система быстро и часто переключается между активными задачами. Хотя AWS заявляет, что микроархитектурные атаки включены в их модель угроз, этот класс атак напрямую зависит от общего оборудования, так же как масштабируемость бессерверных вычислений зависит от совместного использования оборудования между беспрецедентным количеством пользователей.

В этой работе мы исследуем, насколько безопасен Firecracker от микроархитектурных атак. Сначала мы рассмотрим заявленную модель изоляции Firecracker и рекомендуемые передовые методы развертывания, определим потенциальные модели угроз для бессерверных платформ и проанализируем потенциальные слабые места. Затем мы используем доказательства концепции микроархитектурных атак, чтобы проверить изоляцию, обеспечиваемую Firecracker, и обнаруживаем, что она обеспечивает слабую защиту от атак Spectre или MDS. Мы обнаружили два особенно тревожных случая: 1) вариант Medusa, который угрожает виртуальным машинам Firecracker, но не процессам, работающим за их пределами, и не смягчается средствами защиты, рекомендованными AWS, и 2) вариант Spectre-PHT, который остается пригодным для использования даже при соблюдении рекомендуемых контрмер. место и SMT отключен в системе. Подводя итог, мы показываем, что AWS переоценивает безопасность, присущую Firecracker VMM, и предоставляет неполные рекомендации по правильной защите облачных систем, использующих Firecracker.

КОНЦЕПЦИИ CCS

• Безопасность и конфиденциальность → Виртуализация и безопасность; Анализ побочных каналов и меры противодействия.

КЛЮЧЕВЫЕ СЛОВА

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

1. ВВЕДЕНИЕ

Бессерверные вычисления — это новая тенденция в облачных вычислениях, когда поставщики облачных услуг (CSP) предоставляют своим клиентам среды выполнения. Таким образом, клиенты могут сосредоточиться на обслуживании своего функционального кода, оставляя административную работу, связанную с оборудованием, операционной системой (ОС), а иногда и временем выполнения, поставщикам CSP. Распространенные модели бессерверных платформ включают функцию как услугу (FaaS) и контейнер как услугу (CaaS). Поскольку отдельные функции обычно невелики, но каждое из приложений клиентов может выполнять от одной до тысяч функций, поставщики услуг связи стремятся разместить как можно больше функций на одном сервере, чтобы минимизировать время простоя и, в свою очередь, максимизировать прибыль. Довольно упрощенный подход к обслуживанию сред выполнения заключается в запуске контейнеров, которые инкапсулируют процесс с его зависимостями, так что только необходимые файлы для каждого процесса загружаются в виртуальные файловые системы поверх общего ядра. Это сводит переключение между контейнерами к простому переключению контекста между процессами. С другой стороны, полная виртуализация обеспечивает хорошую изоляцию между виртуальными машинами (ВМ) и, следовательно, безопасность между арендаторами, но при этом является довольно тяжелой, поскольку каждая виртуальная машина поставляется со своим собственным ядром.

Ни один из этих подходов, ни контейнер, ни виртуальная машина, не является идеальным для использования в бессерверных средах, где в идеале множество кратковременных функций, принадлежащих многим пользователям, будут выполняться одновременно и часто переключаться, поэтому для этого варианта использования были разработаны новые механизмы изоляции. Например, механизмы изоляции внутри процесса [38, 45, 49] направлены на повышение безопасности контейнеров за счет уменьшения поверхности атаки среды выполнения и базового ядра. Защита ядра важна, поскольку скомпрометированное ядро напрямую приводит к полной компрометации системы в случае контейнера. Однако некоторые мощные средства защиты, такие как ограничение системных вызовов, также ограничивают функциональность, доступную контейнеру, и даже нарушают совместимость с некоторыми приложениями. В ходе исследований виртуальных машин разработчики создавали еще меньшие по размеру и более эффективные виртуальные машины, что в конечном итоге привело к появлению так называемых микровиртуальных машин. МикроVM обеспечивают те же гарантии изоляции, что и обычные виртуальные машины, но их возможности очень ограничены, когда дело касается поддержки устройств или ОС, что делает их более легкими по сравнению с обычными виртуальными машинами и, следовательно, лучше подходят для бессерверных вычислений.

Firecracker [1] — это менеджер виртуальных машин (VMM), предназначенный для запуска микроVM, обеспечивая при этом накладные расходы на память и время запуска, сравнимое со временем запуска обычных контейнерных систем. Firecracker активно разрабатывается Amazon Web Services (AWS) и с 2018 года используется в производстве бессерверных вычислительных сервисов AWS Lambda [5] и AWS Fargate [4] [1]. В проектном документе AWS [1] описаны особенности Firecracker, его отличие от более традиционных виртуальных машин и предполагаемая модель изоляции, которую он обеспечивает: безопасность для «нескольких функций, выполняемых на одном и том же оборудовании, защита от повышения привилегий, информация раскрытие информации, скрытые каналы и другие риски» [1]. Кроме того, AWS предоставляет рекомендации по настройке производственного хоста [8] для защиты частей ЦП и ядра, с которыми взаимодействует виртуальная машина Firecracker. В этой статье мы оспариваем утверждение о том, что Firecracker защищает функции от скрытых и побочных каналов в микроVM. Мы показываем, что Firecracker сам по себе не добавляет к микроархитектурным мерам противодействия атакам, а полностью полагается на хостовые и гостевые ядра Linux и обновления прошивки/микрокода процессора.

Микроархитектурные атаки, такие как различные варианты Spectre [10, 13, 22, 30, 31, 33, 52] и микроархитектурная выборка данных (MDS) [14, 37, 46, 50], представляют угрозу для мультитенантных систем, поскольку они часто способен обходить как программные, так и архитектурные границы изоляции, в том числе границы виртуальных машин. Spectre и MDS угрожают арендаторам, которые совместно используют ресурсы ядра ЦП, такие как блок прогнозирования ветвей (BPU) или буфер заполнения строк (LFB). Поставщики услуг связи, предоставляющие более традиционные услуги, могут смягчить проблему общих аппаратных ресурсов, прикрепив долгоживущих арендаторов виртуальных машин к отдельным ядрам ЦП, что эффективно распределяет ресурсы между арендаторами и гарантирует, что на состояние микроархитектуры одновременно влияет только один арендатор. .

Однако в бессерверных средах угроза микроархитектурных атак выше. Причиной этого является недолговечность функций, выполняемых разными арендаторами. Ожидается, что серверные ресурсы в бессерверных средах будут перегружены, что приведет к тому, что функции арендатора будут конкурировать за вычислительные ресурсы на одном и том же оборудовании. Отключение одновременной многопоточности (SMT), которое отключит одновременное использование ресурсов ЦП двумя одноуровневыми потоками, снижает вычислительную мощность ЦП до 30% [34]. Если клиенты арендуют определенные ядра ЦП, это снижение производительности может быть приемлемым, или оба потока ядра ЦП могут арендоваться вместе. Но для бессерверных сервисов снижение производительности напрямую означает, что за определенный промежуток времени можно обслужить на 30 % меньше клиентов. Вот почему следует предположить, что большинство бессерверных CSP поддерживают SMT в своих системах, если не указано иное. Поверхность микроархитектурной атаки является самой большой, если включен SMT и вредоносный поток имеет одновременный доступ к общему ядру. Но существуют также варианты атак, которые работают так же хорошо, если поток злоумышленника подготавливает микроархитектуру до того, как передать ядро ЦП потоку-жертве, или выполняется сразу после того, как поток-жертва приостановил выполнение. И даже если SMT отключен CSP (как в случае с AWS Lambda), арендаторы по-прежнему делят процессоры с несколькими другими таким образом с разделением по времени.

AWS утверждает, что Firecracker, работающий в системе с современной микроархитектурной защитой, обеспечит достаточную защиту от микроархитектурных атак [1]. Документация Firecracker также содержит конкретные рекомендации по микроархитектурным мерам безопасности, которые следует включить. В этой работе мы изучаем заявления и рекомендации Firecracker по безопасности и выявляем упущения в его руководствах, а также совершенно явные угрозы.

Подводя итог, наш основной вклад заключается в следующем:

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

• Мы тестируем возможности защиты Firecracker от микроархитектурных атак с доказательством концепции (PoC), используя защиту, доступную через обновления микрокода и ядро Linux. Мы показываем, что сама виртуальная машина обеспечивает незначительную защиту от основных классов микроархитектурных атак.

• Мы идентифицируем вариант атаки Medusa MDS, который можно использовать внутри виртуальных машин Firecracker, даже если он отсутствует на хосте. Средства защиты ядра, защищающие от этого эксплойта и большинства известных вариантов Medusa, не упоминаются в рекомендациях по настройке хоста Firecracker от AWS. Кроме того, мы показываем, что отключение SMT обеспечивает недостаточную защиту от выявленного варианта Medusa, что требует принятия мер по снижению риска со стороны ядра.

• Мы идентифицируем варианты Spectre-PHT и Spectre-BTB, которые приводят к утечке данных даже при наличии рекомендуемых мер противодействия. Варианты Spectre-PHT даже остаются проблемой, когда SMT отключен, если злоумышленник и жертва совместно используют ядро ЦП с разделением по времени.

1.1 Ответственное раскрытие информации

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