Новый год начался очень оригинально. Вместо семейных посиделок служба эксплуатации тщательно следила за развитием ситуации с уязвимостями процессоров Meltdown и Spectre. В теории они означали угрозу для данных и ключей клиентов. Если очень коротко, то реализация уязвимостей выглядит так:
— А у вас АКСУ в продаже есть?
— Нету.
— А КПВТ?
— Нету.
— А гранаты?
— Ээх, вот чего нет, того нет.
То есть можно выстроить такую систему запросов, которая опосредованно даст понять, что хранится в оперативной памяти физического хоста по замерам времени ответов процессора. В первой половине января производители ОС и гипервизоров выкатили патчи, которые не дают использовать эту возможность, но при этом режут часть производительности систем.
Мы очень беспокоились за СУБД, потому что именно на них ожидался пик syscall’ов, и потребление ресурсов облака могло вырасти больше чем на 10%.
Забегая чуть вперёд — с патчами MS SQL в некоторых тестах работает почему-то быстрее.
Тесты производительности
Поскольку ничего на облако Техносерв мы без тестов не накатываем, мы подготовились к этим патчам во всеоружии — сделали две среды для тестов, на которые поставили ESXi и WinServer 2012, — старые и, как только вышли обновлённые, соответственно обновлённые.
Результаты тестов получились странные. Смотрите, вот методология тестирования:
Сервер:
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GB RAM
UEFI v2.7.0
Гипервизор: VMware ESXi 6.0 Build 7504637
Виртуальная машина:
VM version 11
8 vCPU (1 socket)
24 GB RAM
Disk 0 (System)Thick provision Eager Zeroed — PVSCSI Controller 0 наDell SC9000 SSD+HDD Profile
Disk 1 (DB Files) Thick provision Eager Zeroed — PVSCSI Controller 1 наDell SC9000 SSD Profile
Disk 2 (Transaction Log Files) Thick provision Eager — PVSCSI Controller 2 наDell SC9000 SSD Profile
NIC: VMXNet3
ОС: Microsoft Windows Server 2012 R2 с2018-01 Monthly Rollup (KB4056895)
DB: Microsoft SQL Server 2016 Enterprise Editions сSP1
Тесты:
7-Zip v16.04 64-Bit (4 CPU Threads / 192 MB Dictionary)
HammerDB v2.23 (32 Warehouses, 8 vUsers, Rampup time 2 min, Test Duration 10 min )
Необновлённая система
Сервер:
Dell PowerEdge R630
2 x Intel Xeon E5-2690 v4 2.6 GHz
320 GB RAM
UEFI v2.6.0
Гипервизор: VMware ESXi 6.0 Build 5572656
Виртуальная машина:
VM version 11
8 vCPU (1 socket)
24 GB RAM
Disk 0 (System)Thick provision Eager Zeroed — PVSCSI Controller 0 наDell SC9000 SSD+HDD Profile
Disk 1 (DB Files) Thick provision Eager Zeroed — PVSCSI Controller 1 наDell SC9000 SSD Profile
Disk 2 (Transaction Log Files) Thick provision Eager — PVSCSI Controller 2 наDell SC9000 SSD Profile
NIC: VMXNet3
ОС: Microsoft Windows Server 2012 R2 с2017-12 Monthly Rollup (KB4054519)
DB: Microsoft SQL Server 2016 Enterprise Editions сSP1
Тесты:
7-Zip v16.04 64-Bit (4 CPU Threads / 192 MB Dictionary)
HammerDB v2.23 (32 Warehouses, 8 vUsers, Rampup time 2 min, Test Duration 10 min)
А вот результаты:
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.
Признаков эксплоитов, действовавших до установления защиты, мы не обнаружили.
Подробная оценка уязвимости позволяет предположить, что нет почти никакого резона ей пользоваться именно в крупных облаках — просто очень тяжело сделать направленную атаку. Да, злоумышленник мог развернуть свой процесс, опрашивающий память ядра или чужого процесса, но при этом только на том же физическом хосте, где расположена его виртуальная машина и чья-то ещё. То есть надо:
- Знать, что цель находится именно в этом облаке.
- Протащить зловредный процесс, который не детектится потоковой защитой.
- Развернуть его на том же физическом хосте, где и цель.
Последнее крайне маловероятно, если вы не выкупите как минимум половину ресурсов публичного облака. VMWare DRS хоть и отрабатывает, но перемещает незначительную часть VM.
Инфраструктурные сервисы работают в отдельном ресурсном кластере, т.е. у нас есть физическое разделение хостов, где крутятся виртуальные машины клиентов, а где виртуальные машины инфраструктуры.
Те, кто находятся в приватных облаках, вообще ни о чём не беспокоились. У них общая СХД с другими системами (а с дисков уязвимость читать ничего не позволяет) и собственный набор хостов.
Когда нужно масштабироваться — добавляются чистые хосты.
Итог — сейчас мы закрылись от основной угрозы и рекомендуем клиентам пропатчить свои ОС. Хотя бы потому, что поддерживать ОС в актуальном состоянии — хороший тон. Уязвимость после детального рассмотрения кажется вопиющей, но не такой опасной и беспокоящей, как казалось в первые дни.
Это материал руководителя службы эксплуатации облака Техносерв Дмитрия Максимова
Комментарии (17)
relclick
12.01.2018 17:30За тесты спасибо, значит слухи о значительном ухудшении производительности пока не подтверждаются.
И еще вопрос — если верить описанию уязвимости на сайте vmware, то обновление для ESXI 6.0, закрывающее в том числе и эту уязвимость, было доступно еще 9-го ноября (Patch Severity Important), поэтому что мешало вовремя поставить важные патчи а не заниматься срочным обновлением инфраструктуры на праздниках? :)
TS_Cloud Автор
12.01.2018 18:44Мы не накатываем патчи без тестов.
Патчи, доступные 9-го ноября, находились еще в стадии тестирования. Так как в середине декабря мы заморозили работы на инфраструктуре перед НГ праздниками, они не были установлены.
Dreadn0ught
12.01.2018 20:56Значит, что атака актуальна только для корпоративного шпионажа? Для большинства «хакеров» уязвимость вовсе не реализуема?
TS_Cloud Автор
13.01.2018 17:18В облаках архитектуры подобных нашему практически невозможно было провести прямую атаку на конкретного клиента. В случае, если этот клиент пользуется персональным облаком уязвимость вообще не может быть реализована.
Sleuthhound
13.01.2018 11:03А где тесты на linux дистрибутивах? А где тесты на судб уровня oracle, postgresql, mysql? Ничего этого нет, о чем тогда статья? По сути только о продуктах MS.
Вы никогда не найдете следов эксплоита meltdown потому что он не оставляет следов.TS_Cloud Автор
13.01.2018 17:19У нас основные клиенты используют MS. Мы писали о своих тестах, которые могут показаться кому-то полезными. На всеохватывающее мировое знание, естественно, не претендуем. Если вы проведёте тесты описанных инфраструктур, будет очень интересно взглянуть.
vsespb
13.01.2018 13:54+2Подробная оценка уязвимости позволяет предположить, что нет почти никакого резона ей пользоваться именно в крупных облаках — просто очень тяжело сделать направленную атаку.
Странный какой-то анализ. Берёшь на любом вашем сервере сканируешь всю память и продаёшь всё найденное похожее на ключи. А покупатели уже разберуться что за ключи и от чего.TS_Cloud Автор
13.01.2018 17:22С удовольствием продадим вам все наши хосты для попытки проведения вами целевой атаки. Если серьезно, то злоумышленник не сможет перемещать свою VM между хостами, то есть, повторюсь, нужно будет выкупить очень много ресурсов и равномерно «размазать» их по облаку, что не очень реалистично. Это в случае, если нет обновленя. После обновления это вообще не сработает.
vsespb
14.01.2018 01:37Да почему вы считаете что атак должна быть целевой на какого-то конкретного клиента. Meltdown позволяет читать всю память со скоростью 500кб / сек. Берём любую виртуалку, читаем всю память, всех клиентов, что там.
Ладно, к чёрту ключи. Находим просто исходники программ на интерпретируемых языках (или байткод), статику сайта (js, html). Исходники уже смотрим вручную. По исходникам понимаем что за сайт, его адрес. Находим кучу дыр (да, если сейчас увидеть исходники какого-то вебпроекта, там средний специалист за несколько часов найдёт несколько критических уязвимостей), кроме дыр там будут пароли, ключи, shared secret, пароли для обращения к внешним API, итп.
Hardened
15.01.2018 12:23Тест странный для сценария виртуализации — на хосте запущена одна единственная мега ВМ и проводятся измерения ее пиковой производительности.
Вектор атаки другой и тест должен быть другой — запустите одновременно несколько ВМ и посмотрите, будет ли просадка производительности. Интересуют изменения в работе resource sсheduler после патча VMware.
relclick
Здравствуйте. Подскажите, как факт наличия общей СХД влияет на уязвимость процессора?
Также интересует, обновляли ли вы микрокод процессоров или ограничились установкой патчей на гипервизор?
TS_Cloud Автор
Данные уязвимости не затрагивают СХД. Реализация возможна только на том физическом хосте, где развёрнуты и атакующая и атакуемая машины. В случае реализации успешной атаки можно вычитать только содержимое оперативной памяти с этого физического хоста, но не получить данные с других хостов. Патч для VMware ESXi включают в себя обновления микрокода для процессоров:
VIBs Installed: VMware_bootbank_cpu-microcode_6.0.0-3.81.7504637, VMware_bootbank_esx-base_6.0.0-3.81.7504637, VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-bootbank_esx-ui_1.22.0-6282878, VMware_bootbank_esx-xserver_6.0.0-3.76.6856897, VMware_bootbank_ipmi-ipmi-devintf_39.1-5vmw.600.3.79.6921384, VMware_bootbank_ipmi-ipmw.600.3.79.6921384, VMware_bootbank_misc-drivers_6.0.0-3.79.6921384, VMware_bootbank_vsan_6.0.0-3.81.7355197, VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.3.81.735519s-light_6.0.0-3.76.6856897