Как смягчить уязвимость SRBDS (CVE-2020-0543) без перезагрузки сервера

Недавно ученые из Группы системной и сетевой безопасности Врије университета (VUSec) опубликовали детали уязвимости CrossTalk или SRBDS (CVE-2020-0543) в процессорах Intel. Уязвимость CrossTalk позволяет коду, контролируемому злоумышленником, выполняющемуся на одном ядре ЦП, утекать конфиденциальные данные из другого программного обеспечения, работающего на другом ядре. В этой статье мы покажем, как смягчить эту уязвимость процессора Intel без перезагрузки сервера.

Что такое CrossTalk?

Уязвимость CrossTalk является типом атаки MDS (микроархитектурная выборка данных), аналогичной Spectre, Meltdown или Zombieload. Она позволяет раскрывать и красть конфиденциальные данные, пока машина к ним обращается. Атаки MDS нацелены на пользовательские данные, находящиеся в переходном состоянии, так как они находятся внутри ЦП и многих систем, подключенных к нему.

Уязвимость SRBDS/CrossTalk является уязвимостью временного выполнения. Названная «Специальная выборка данных из буфера регистров» или SRBDS (CVE-2020-0543) компанией Intel, она позволяет коду, контролируемому злоумышленником, выполняющемуся на одном ядре ЦП, утекать конфиденциальные данные из программного обеспечения жертвы, выполняющегося на другом ядре.

Рисунок 1: Дизайн этапа профилирования инструкций CrossTalk, любезно предоставленный VUSec

Любая система, использующая процессор Intel, может быть подвержена этой уязвимости. Проверьте здесь, затрагивает ли ваша ЦП эту уязвимость.

Смягчение уязвимости SRBDS (CVE-2020-0543) без перезагрузки

Intel реализовала свое смягчение для уязвимости SRBDS в обновлении микрокода, распространенном среди поставщиков программного обеспечения во вторник, 9 июня 2020 года. Это смягчение требует установки последних патчей ядра Linux и обновления микрокода. Оба действия традиционно выполняются при перезагрузке.

Хотя перезагрузка нескольких серверов не кажется проблемой, если вы системный администратор, заботящийся о более чем 500 серверах, это определенно проблема. Перезагрузка целого парка серверов обычно требует тщательного планирования окна обслуживания. К счастью, технология живого патчинга позволяет применять обновления безопасности систем против CrossTalk без перезагрузки, как для обновления микрокода, так и для применения патчей ядра Linux.

Canonical, Red Hat и другие поставщики дистрибутивов выпустили патчи безопасности для всех поддерживаемых дистрибутивов Ubuntu, Debian, CentOS, Red Hat Enterprise Linux. И хотя Canonical и Red Hat имеют свои собственные решения для патчинга уязвимостей без перезагрузки, в случае SRBDS/CrossTalk вам все равно нужно перезагрузить рабочую станцию или сервер после обновления.

Команда KernelCare создала смягчение без перезагрузки для CrossTalk/SRBDS, чтобы вы могли избежать перезагрузки серверов для применения патчей. Найдите инструкции ниже:

A) Если вы работаете на аппаратном обеспечении, выполните 3 шага, чтобы защитить свои серверы от уязвимости CrossTalk/SRBDS без перезагрузки:

Шаг 1: Зарегистрируйтесь для получения бесплатной пробной лицензии KernelCare

KernelCare можно использовать бесплатно в течение 30 дней на всех ваших серверах, для регистрации пробной версии не требуется кредитная карта. Он также бесплатен для организаций здравоохранения до конца 2020 года и навсегда бесплатен для некоммерческих организаций.

Шаг 2: Обновите микрокод без перезагрузки

Пример: Обновление микрокода на RHEL

Это пример обновления микрокода без перезагрузки на RHEL. Инструкции для Debian, Ubuntu, CentOS и других дистрибутивов можно найти в документации KernelCare.

Для дистрибутивов на базе RHEL вы можете использовать утилиту microcode_ctl для обновления микрокода.

Перед тем как начать, проверьте здесь, готовы ли патчи для вашего дистрибутива. Страница обновляется каждый час.

Получите последний микрокод, обновив пакет microcode_ctl

yum update microcode_ctl

Создайте force-late-intel–06–4f–01 внутри каталога прошивки.

touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01

Запустите обновление микрокода

/usr/libexec/microcode_ctl/update_ucode

Принудите ядро загрузить новый микрокод

echo 1 > /sys/devices/system/cpu/microcode/reload

Проверьте новый микрокод

dmesg | grep microcode  
[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12  
[ 2.254820] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba  
[ 1483.494573] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.495985] microcode: updated to revision 0x21, date = 2019-02-13  
[ 1483.496012] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.496698] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.497391] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

(Необязательно) Дважды проверьте новую версию микрокода (ревизии на ядро)

cat /proc/cpuinfo | grep -e microcode  
microcode : 0x21  
microcode : 0x21  
microcode : 0x21  
microcode : 0x21

Шаг 3: Примените патчи KernelCare

Теперь вам нужно обновить ядро Linux, чтобы гарантировать, что локальный пользователь не может читать данные, которые вы выполняете на ЦП. С KernelCare вы можете сделать это без перезагрузки. Если вы зарегистрировались для пробной версии на Шаге 1 - вы готовы и не должны делать ничего другого.

B) Если вы работаете на ВМ:

Вам нужно только патчить ядро Linux внутри ВМ. Убедитесь, что ваш хост-узел также обновлен, что обычно делает ваш поставщик услуг.

Если вы используете свой KernelCare - ваши патчи будут автоматически доставлены KernelCare, и вам не нужно делать ничего лишнего. Если нет - зарегистрируйтесь для бесплатной 30-дневной пробной версии.