Комментарии 21
Те, кто находятся в приватных облаках, вообще ни о чём не беспокоились. У них общая СХД с другими системами (а с дисков уязвимость читать ничего не позволяет) и собственный набор хостов.
Здравствуйте. Подскажите, как факт наличия общей СХД влияет на уязвимость процессора?
Также интересует, обновляли ли вы микрокод процессоров или ограничились установкой патчей на гипервизор?
Данные уязвимости не затрагивают СХД. Реализация возможна только на том физическом хосте, где развёрнуты и атакующая и атакуемая машины. В случае реализации успешной атаки можно вычитать только содержимое оперативной памяти с этого физического хоста, но не получить данные с других хостов. Патч для 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
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
За тесты спасибо, значит слухи о значительном ухудшении производительности пока не подтверждаются.
И еще вопрос — если верить описанию уязвимости на сайте vmware, то обновление для ESXI 6.0, закрывающее в том числе и эту уязвимость, было доступно еще 9-го ноября (Patch Severity Important), поэтому что мешало вовремя поставить важные патчи а не заниматься срочным обновлением инфраструктуры на праздниках? :)
И еще вопрос — если верить описанию уязвимости на сайте vmware, то обновление для ESXI 6.0, закрывающее в том числе и эту уязвимость, было доступно еще 9-го ноября (Patch Severity Important), поэтому что мешало вовремя поставить важные патчи а не заниматься срочным обновлением инфраструктуры на праздниках? :)
Для серверов так же важно потребление электричества и некоторые уже писали о повышенном нагреве. Вы делали такие замеры?
Признаков эксплоитов, действовавших до установления защиты, мы не обнаружили.А разве они оставляют следы? )
Значит, что атака актуальна только для корпоративного шпионажа? Для большинства «хакеров» уязвимость вовсе не реализуема?
А микрокод тоже был обновлен?
А где тесты на linux дистрибутивах? А где тесты на судб уровня oracle, postgresql, mysql? Ничего этого нет, о чем тогда статья? По сути только о продуктах MS.
Вы никогда не найдете следов эксплоита meltdown потому что он не оставляет следов.
Вы никогда не найдете следов эксплоита meltdown потому что он не оставляет следов.
Подробная оценка уязвимости позволяет предположить, что нет почти никакого резона ей пользоваться именно в крупных облаках — просто очень тяжело сделать направленную атаку.
Странный какой-то анализ. Берёшь на любом вашем сервере сканируешь всю память и продаёшь всё найденное похожее на ключи. А покупатели уже разберуться что за ключи и от чего.
С удовольствием продадим вам все наши хосты для попытки проведения вами целевой атаки. Если серьезно, то злоумышленник не сможет перемещать свою VM между хостами, то есть, повторюсь, нужно будет выкупить очень много ресурсов и равномерно «размазать» их по облаку, что не очень реалистично. Это в случае, если нет обновленя. После обновления это вообще не сработает.
Да почему вы считаете что атак должна быть целевой на какого-то конкретного клиента. Meltdown позволяет читать всю память со скоростью 500кб / сек. Берём любую виртуалку, читаем всю память, всех клиентов, что там.
Ладно, к чёрту ключи. Находим просто исходники программ на интерпретируемых языках (или байткод), статику сайта (js, html). Исходники уже смотрим вручную. По исходникам понимаем что за сайт, его адрес. Находим кучу дыр (да, если сейчас увидеть исходники какого-то вебпроекта, там средний специалист за несколько часов найдёт несколько критических уязвимостей), кроме дыр там будут пароли, ключи, shared secret, пароли для обращения к внешним API, итп.
Ладно, к чёрту ключи. Находим просто исходники программ на интерпретируемых языках (или байткод), статику сайта (js, html). Исходники уже смотрим вручную. По исходникам понимаем что за сайт, его адрес. Находим кучу дыр (да, если сейчас увидеть исходники какого-то вебпроекта, там средний специалист за несколько часов найдёт несколько критических уязвимостей), кроме дыр там будут пароли, ключи, shared secret, пароли для обращения к внешним API, итп.
Конечно, такая атака возможна. Просто, кажется, что её ценность ниже. Ведь на одной физической машине размещается не так много заказчиков, далеко не каждый из них — интересный кому-то вэб-проект, может так случиться, что большинство виртуальных машин окажутся либо служебными, либо какой-нибудь test средой и так далее.
Наконец, каждый заказчик в облаке подписывает договор, известны его установочные данные (как минимум через оплату счёта). Значит атаковать со своей машины рискованно. Перед атакой нужно будет ещё и взломать чью-то чужую виртуальную машину, размещённую в облаке.
Безусловно, в любом случае защищаться от этой уязвимости нужно, потенциально она очень опасна. При этом вероятность пострадать конкретному заказчику, размещённому в облаке, не очень высока.
Наконец, каждый заказчик в облаке подписывает договор, известны его установочные данные (как минимум через оплату счёта). Значит атаковать со своей машины рискованно. Перед атакой нужно будет ещё и взломать чью-то чужую виртуальную машину, размещённую в облаке.
Безусловно, в любом случае защищаться от этой уязвимости нужно, потенциально она очень опасна. При этом вероятность пострадать конкретному заказчику, размещённому в облаке, не очень высока.
Meltdown позволяет читать всю память со скоростью 500кб / сек
Meltdown никак не позволяет читать память за пределами гостевой ОС (если речь идет об аппаратной виртуализации).
Единственный вектор атаки для guest->hypervisor или guest<->guest — это Spectre v2. А в этом случае единственное, что можно будет сделать, это при удачном стечении обстоятельств «натренировать» процесс за пределами ВМ обращаться к своей же памяти, но по незапланированному адресу. После чего все еще будет нужен сторонний способ для обращения в ту же область памяти этого процесса, чтобы попытаться сделать какой-либо вывод о содержимом памяти по интересующему адресу. Все это в совокупности сводит такой тип атаки в случае стандратной конфигурации (в частности отстутсвуют нестандартные опции ядра, облегчающие вторую часть эксплуатации уязвимости) к крайне маловероятной.
Тест странный для сценария виртуализации — на хосте запущена одна единственная мега ВМ и проводятся измерения ее пиковой производительности.
Вектор атаки другой и тест должен быть другой — запустите одновременно несколько ВМ и посмотрите, будет ли просадка производительности. Интересуют изменения в работе resource sсheduler после патча VMware.
Вектор атаки другой и тест должен быть другой — запустите одновременно несколько ВМ и посмотрите, будет ли просадка производительности. Интересуют изменения в работе resource sсheduler после патча VMware.
Какие патчи в итоге поставили в продуктив? Ноябрьский 6921384 или январский 7504637? Тестировали вы на втором, но вот он был отозван через несколько дней. И процессоры на стенде у вас как раз подвержены проблеме. См. https://kb.vmware.com/s/article/52345
И можно, пожалуйста, подробнее про тестирование? Что именно тестируете?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Meltdown и Spectre для облака: наша оценка рисков и как мы патчились