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



    Новый год начался очень оригинально. Вместо семейных посиделок служба эксплуатации тщательно следила за развитием ситуации с уязвимостями процессоров 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.

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

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

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

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

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

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



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

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

    Это материал руководителя службы эксплуатации облака Техносерв Дмитрия Максимова
    ТЕХНОСЕРВ 102,98
    Компания
    Поделиться публикацией
    Комментарии 18
    • +1
      Те, кто находятся в приватных облаках, вообще ни о чём не беспокоились. У них общая СХД с другими системами (а с дисков уязвимость читать ничего не позволяет) и собственный набор хостов.

      Здравствуйте. Подскажите, как факт наличия общей СХД влияет на уязвимость процессора?
      Также интересует, обновляли ли вы микрокод процессоров или ограничились установкой патчей на гипервизор?

      • 0
        Данные уязвимости не затрагивают СХД. Реализация возможна только на том физическом хосте, где развёрнуты и атакующая и атакуемая машины. В случае реализации успешной атаки можно вычитать только содержимое оперативной памяти с этого физического хоста, но не получить данные с других хостов. Патч для 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
      • 0
        За тесты спасибо, значит слухи о значительном ухудшении производительности пока не подтверждаются.
        И еще вопрос — если верить описанию уязвимости на сайте vmware, то обновление для ESXI 6.0, закрывающее в том числе и эту уязвимость, было доступно еще 9-го ноября (Patch Severity Important), поэтому что мешало вовремя поставить важные патчи а не заниматься срочным обновлением инфраструктуры на праздниках? :)
        • 0
          Мы не накатываем патчи без тестов.
          Патчи, доступные 9-го ноября, находились еще в стадии тестирования. Так как в середине декабря мы заморозили работы на инфраструктуре перед НГ праздниками, они не были установлены.
        • 0
          Для серверов так же важно потребление электричества и некоторые уже писали о повышенном нагреве. Вы делали такие замеры?
          • 0
            Замеры по энергопотреблению не проводили. Оценить энергопотребление сможем в следующем месяце. Уже по фактическим затратам.
            • 0

              обязательно отпишитесь. Очень интересен рез-т

          • +1
            Признаков эксплоитов, действовавших до установления защиты, мы не обнаружили.
            А разве они оставляют следы? )
            • –2
              Мы изучили вопрос возможных атак, и ничего подозрительного не обнаружили, не было и обращений со стороны клиентов.
            • 0
              Значит, что атака актуальна только для корпоративного шпионажа? Для большинства «хакеров» уязвимость вовсе не реализуема?
              • 0
                В облаках архитектуры подобных нашему практически невозможно было провести прямую атаку на конкретного клиента. В случае, если этот клиент пользуется персональным облаком уязвимость вообще не может быть реализована.
              • 0
                А микрокод тоже был обновлен?
                • 0
                  А где тесты на linux дистрибутивах? А где тесты на судб уровня oracle, postgresql, mysql? Ничего этого нет, о чем тогда статья? По сути только о продуктах MS.
                  Вы никогда не найдете следов эксплоита meltdown потому что он не оставляет следов.
                  • 0
                    У нас основные клиенты используют MS. Мы писали о своих тестах, которые могут показаться кому-то полезными. На всеохватывающее мировое знание, естественно, не претендуем. Если вы проведёте тесты описанных инфраструктур, будет очень интересно взглянуть.
                  • +3
                    Подробная оценка уязвимости позволяет предположить, что нет почти никакого резона ей пользоваться именно в крупных облаках — просто очень тяжело сделать направленную атаку.

                    Странный какой-то анализ. Берёшь на любом вашем сервере сканируешь всю память и продаёшь всё найденное похожее на ключи. А покупатели уже разберуться что за ключи и от чего.
                    • 0
                      С удовольствием продадим вам все наши хосты для попытки проведения вами целевой атаки. Если серьезно, то злоумышленник не сможет перемещать свою VM между хостами, то есть, повторюсь, нужно будет выкупить очень много ресурсов и равномерно «размазать» их по облаку, что не очень реалистично. Это в случае, если нет обновленя. После обновления это вообще не сработает.
                      • +1
                        Да почему вы считаете что атак должна быть целевой на какого-то конкретного клиента. Meltdown позволяет читать всю память со скоростью 500кб / сек. Берём любую виртуалку, читаем всю память, всех клиентов, что там.
                        Ладно, к чёрту ключи. Находим просто исходники программ на интерпретируемых языках (или байткод), статику сайта (js, html). Исходники уже смотрим вручную. По исходникам понимаем что за сайт, его адрес. Находим кучу дыр (да, если сейчас увидеть исходники какого-то вебпроекта, там средний специалист за несколько часов найдёт несколько критических уязвимостей), кроме дыр там будут пароли, ключи, shared secret, пароли для обращения к внешним API, итп.

                    • 0
                      Тест странный для сценария виртуализации — на хосте запущена одна единственная мега ВМ и проводятся измерения ее пиковой производительности.

                      Вектор атаки другой и тест должен быть другой — запустите одновременно несколько ВМ и посмотрите, будет ли просадка производительности. Интересуют изменения в работе resource sсheduler после патча VMware.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое