Поиск по сайту:

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


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

Что такое перекрестный разговор?

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

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

Эта уязвимость может затронуть любую систему, использующую процессор Intel. Проверьте здесь, если ваш процессор затронут.

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

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

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

Canonical, Red Hate и другие поставщики дистрибутивов выпустили исправления безопасности для всех поддерживаемых дистрибутивов 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 для обновления микрокода.

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

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

yum update microcode_ctl

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

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

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

/usr/libexec/microcode_ctl/update_ucode

4. Заставить ядро загрузить новый микрокод

эхо 1 > /sys/devices/system/cpu/microcode/reload

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

dmesg | grep microcode
[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12
[ 2.254820] microcode: Microcode Update Driver: v2.01 <>, 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

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

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

Шаг 3. Примените исправления KernelCare

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

Б) Если вы работаете на виртуальной машине:

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

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