Meltdown и Spectre для облака: наша оценка рисков и как мы патчились

Новый год начался очень оригинально. Вместо семейных посиделок служба эксплуатации тщательно следила за развитием ситуации с уязвимостями процессоров Meltdown и Spectre. В теории они означали угрозу для данных и ключей клиентов. Если очень коротко, то реализация уязвимостей выглядит так:

— А у вас АКСУ в продаже есть?
— Нету.
— А КПВТ?
— Нету.
— А гранаты?
— Ээх, вот чего нет, того нет.

То есть можно выстроить такую систему запросов, которая опосредованно даст понять, что хранится в оперативной памяти физического хоста по замерам времени ответов процессора. В первой половине января производители ОС и гипервизоров выкатили патчи, которые не дают использовать эту возможность, но при этом режут часть производительности систем.

Мы очень беспокоились за СУБД, потому что именно на них ожидался пик syscall’ов, и потребление ресурсов облака могло вырасти больше чем на 10%.

Забегая чуть вперёд — с патчами MS SQL в некоторых тестах работает почему-то быстрее.

Тесты производительности

Поскольку ничего на облако Техносерв Cloud мы без тестов не накатываем, мы подготовились к этим патчам во всеоружии — сделали две среды для тестов, на которые поставили ESXi и WinServer 2012, — старые и, как только вышли обновлённые, соответственно обновлённые.

Результаты тестов получились странные. Смотрите, вот методология тестирования:


А вот результаты:

patched


unpatched


patched


unpatched


patched


unpatched


В более тяжелом тесте обновлённая система демонстрирует немного меньшую производительность:

HammerDB v2.23 (Warehouses: 128; vUsers: 24; Total Transactions per User: 1000000; Rampup time: 2 min; Test Duration: 10 min; User Delay: 500ms; Repeat Delay: 500 ms)

unpatched


unpatched


patched


patched


SQL — в некоторых тестах результаты пропатченной системы выше (быстрее), чем в непропатченной. Это очень странно. Объяснить этот феномен я не могу — возможно, дело в том, что с кумулятивным обновлением пришло что-то ещё, что оптимизирует работу. Да, мы давали синтетическую нагрузку, но всё же довольно сильно похожую на ту, что в продакшне, поэтому вряд ли дело в самом методе исследования.

Для более сложных тестов просадка производительности заметна, но она не превысила 10%.

Оценка угрозы

На запатченном гипервизоре уже неважно, какую гостевую операционную систему (запатченную или нет) использует клиент облака. То есть после обновлений (а они уже сделаны, ушло в общей сложности 4 дня на всю инфраструктуру — это чтобы без простоев, аккуратно мигрируя ВМ туда-сюда) — облако защищено от Spectre и Metldown.

Признаков эксплоитов, действовавших до установления защиты, мы не обнаружили.

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

1. Знать, что цель находится именно в этом облаке.
2. Протащить зловредный процесс, который не детектится потоковой защитой.
3. Развернуть его на том же физическом хосте, где и цель.

Последнее крайне маловероятно, если вы не выкупите как минимум половину ресурсов публичного облака. VMWare DRS хоть и отрабатывает, но перемещает незначительную часть VM.

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

Те, кто находятся в приватных облаках, вообще ни о чём не беспокоились. У них общая СХД с другими системами (а с дисков уязвимость читать ничего не позволяет) и собственный набор хостов.



Когда нужно масштабироваться — добавляются чистые хосты.

Итог — сейчас мы закрылись от основной угрозы и рекомендуем клиентам пропатчить свои ОС. Хотя бы потому, что поддерживать ОС в актуальном состоянии — хороший тон. Уязвимость после детального рассмотрения кажется вопиющей, но не такой опасной и беспокоящей, как казалось в первые дни.

Это материал руководителя службы эксплуатации облака Техносерв Cloud Дмитрия Максимова