Проверьте наличие уязвимостей Meltdown и Spectre и исправьте их в Linux

После полного обновления системы Arch перезагрузитесь и снова запустите приведенные выше команды. Если ваша система исправлена, вы должны увидеть следующий вывод для первой команды:

CONFIG_PAGE_TABLE_ISOLATION=y

И вы получите этот вывод для второй команды.

[ 0.000000] Kernel/User page tables isolation: enabled

Я уже обновил ядро в своей системе Arch. Как вы видите в приведенном выше выводе, мое ядро Linux — 4.14.12-1-ARCH, и оно уже исправлено. Если вы еще не обновили свою систему Arch, вы не получите никаких результатов.

Вышеуказанные команды могут не работать в Ubuntu. К счастью, некоторые добрые самаритяне на форуме Askubuntu опубликовали обходной путь, позволяющий узнать, исправлены ли ваши системы Ubuntu или нет, с помощью любой из следующих команд.

grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched :)" || echo "unpatched :("

grep cpu_insecure /proc/cpuinfo && echo "patched :)" || echo "unpatched :("

dmesg | grep "Kernel/User page tables isolation: enabled" && echo "patched :)" || echo "unpatched :("

Если вывод не исправлен, ваша система еще не исправлена. Немедленно обновите ядро, чтобы применить исправления.

Я до сих пор использую 4.4.0-104-generic в своей системе Ubuntu, поэтому в результате всех команд я получаю «непропатченный».

Немедленно обновите ядро, используя команду:

sudo apt-get update

sudo apt-get dist-upgrade

Или как описано по следующей ссылке.

• Утилиты ядра Linux — сценарии для компиляции и обновления последней версии ядра Linux для Debian и его производных

После обновления ядра снова запустите эти три команды, и вы увидите, что ваша система Ubuntu исправлена!

Для других дистрибутивов Linux существует сценарий под названием "Spectre & Meltdown Checker" для проверки уязвимостей Meltdown/Spectre. Этот скрипт поможет определить, уязвима ли ваша установка Linux перед тремя CVE «спекулятивного выполнения».

Git клонирует этот скрипт:

git clone https://github.com/speed47/spectre-meltdown-checker.git

Это клонирует все содержимое каталога с именем «spectre-meltdown-checker» в вашем текущем рабочем каталоге.

Перейдите в этот каталог:

cd spectre-meltdown-checker/

Сделайте скрипт исполняемым:

chmod +x spectre-meltdown-checker.sh

Наконец запустите его, чтобы найти уязвимости:

sudo ./spectre-meltdown-checker.sh

Вот пример вывода моей пропатченной системы Ubuntu:

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

Обновление:

Скрипт spectre-meltdown-checker доступен в официальных репозиториях некоторых дистрибутивов Linux.

В Дебиане, Убунту:

sudo apt install spectre-meltdown-checker

В CentOS RHEL:

sudo yum install epel-release

sudo yum install spectre-meltdown-checker

В Федоре:

sudo dnf install $ sudo apt install spectre-meltdown-checker

После установки spectre-meltdown-checker запустите его от имени пользователя root или с привилегиями sudo, чтобы проверить наличие уязвимостей Spectre и Meltdown:

sudo spectre-meltdown-checker

Пример вывода:

Spectre and Meltdown mitigation detection tool v0.37

Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64
CPU is Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  NO 
    * CPU indicates IBRS capability:  NO 
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  NO 
    * CPU indicates IBPB capability:  NO 
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  NO 
    * CPU indicates STIBP capability:  NO 
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO 
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO 
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 
  * CPU microcode is known to cause stability problems:  NO  (model 42 stepping 7 ucode  cpuid 0x206a7)
* CPU vulnerability to the three speculative execution attack variants
  * Vulnerable to Variant 1:  YES 
  * Vulnerable to Variant 2:  YES 
  * Vulnerable to Variant 3:  YES 

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers)
* Kernel has array_index_mask_nospec (x86):  UNKNOWN  (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package))
* Kernel has the Red Hat/Ubuntu patch:  UNKNOWN  (missing 'strings' tool, please install it, usually it's in the binutils package)
* Kernel has mask_nospec64 (arm):  UNKNOWN  (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package))
* Checking count of LFENCE instructions following a jump in kernel...  UNKNOWN  (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package))
> STATUS:  VULNERABLE  (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  NO  (Vulnerable, STIBP: disabled)
* Mitigation 1
  * Kernel is compiled with IBRS support:  YES 
    * IBRS enabled and active:  UNKNOWN 
  * Kernel is compiled with IBPB support:  UNKNOWN  (in offline mode, we need the kernel image to be able to tell)
    * IBPB enabled and active:  NO 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  YES 
> STATUS:  VULNERABLE  (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability)

> How to fix: To mitigate this vulnerability, you need either IBRS + IBPB, both requiring hardware support from your CPU microcode in addition to kernel support, or a kernel compiled with retpoline and IBPB, with retpoline requiring a retpoline-aware compiler (re-run this script with -v to know if your version of gcc is retpoline-aware) and IBPB requiring hardware support from your CPU microcode. The retpoline + IBPB approach is generally preferred as the performance impact is lower. More information about how to enable the missing bits for those two possible mitigations on your system follow. You only need to take one of the two approaches.

> How to fix: The microcode of your CPU needs to be upgraded to be able to use IBPB. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). An updated CPU microcode will have IBRS/IBPB capabilities indicated in the Hardware Check section above. If you're running under an hypervisor (KVM, Xen, VirtualBox, VMware, ...), the hypervisor needs to be up to date to be able to export the new host CPU flags to the guest. You can run this script on the host to check if the host CPU is IBRS/IBPB. If it is, and it doesn't show up in the guest, upgrade the hypervisor.

> How to fix: Your kernel doesn't have IBPB support, so you need to either upgrade your kernel (if you're using a distro) or recompiling a more recent kernel.

> How to fix: The microcode of your CPU needs to be upgraded to be able to use IBRS. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). An updated CPU microcode will have IBRS/IBPB capabilities indicated in the Hardware Check section above. If you're running under an hypervisor (KVM, Xen, VirtualBox, VMware, ...), the hypervisor needs to be up to date to be able to export the new host CPU flags to the guest. You can run this script on the host to check if the host CPU is IBRS/IBPB. If it is, and it doesn't show up in the guest, upgrade the hypervisor.

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  NO  (Vulnerable)
* Kernel supports Page Table Isolation (PTI):  YES 
  * PTI enabled and active:  NO 
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

> How to fix: If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel with the CONFIG_PAGE_TABLE_ISOLATION option (named CONFIG_KAISER for some kernels), or the CONFIG_UNMAP_KERNEL_AT_EL0 option (for ARM64)

A false sense of security is worse than no security at all, see --disclaimer

Как вы можете видеть из приведенного выше вывода, проблемы Spectre и Meltdown еще не исправлены.

Исправление уязвимостей Meltdown и Spectre

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

Чтобы обновить/обновить Arch Linux, запустите:

sudo pacman -Syu

Чтобы обновить Debian, Ubuntu:

sudo apt-get update && sudo apt-get dist-upgrade

Чтобы обновить Fedora:

sudo dnf update

Чтобы обновить RHEL/CentOS:

sudo yum update

После обновления вашей системы Linux не забудьте перезагрузить ее.

Опять же, помните, что эти проблемы еще не полностью решены. Вам необходимо продолжать обновлять свои системы Linux в течение следующих нескольких недель, пока все не будет исправлено.

Рекомендуем прочитать:

• Как заставить систему Linux работать быстрее на процессорах Intel

Ресурсы:

• /r/archlinux
• НиксКрафт
• Аскубунту