GNU/Linux >> Linux Esercitazione >  >> Linux

Come verificare la presenza di vulnerabilità di Meltdown e Spectre e correggerle in Linux

All'inizio di questa settimana, un team di ricercatori del Project Zero di Google ha scoperto su Tracollo e Spettro vulnerabilità che hanno interessato molti processori moderni, inclusi alcuni processori Intel, AMD e ARM. Anche se AMD ha affermato che non ci sono possibilità che i loro processori siano interessati da questi difetti, i ricercatori hanno indicato che la vulnerabilità Meltdown è esclusiva dei processori Intel, mentre la vulnerabilità Spectre può interessare alcuni processori Intel, AMD e ARM.

Secondo Cablato , "i produttori di Intel, AMD e ARM stanno lavorando a stretto contatto e collaborando con società di hardware che spediscono i loro processori e società di software come Apple, Google, Microsoft, la fondazione Linux per rilasciare patch per questi difetti di sicurezza. Non possiamo assicurarlo le patch risolveranno completamente questi problemi. Ma, almeno, meglio di come sembrava prima".

Cosa puoi fare adesso?

Greg Kroah-Hartman ha già annunciato il rilascio dei kernel stabili 4.14.12, 4.9.75 e 4.4.110 che vengono forniti con il meltdown e le correzioni di Spectre. Quindi, se stai utilizzando un processore Intel o AMD o ARM, ti consigliamo vivamente di verificare se il tuo sistema Linux è interessato dalle vulnerabilità di Meltdown e Spectre e correggerlo immediatamente aggiornando l'ultimo kernel Linux. Se la tua distribuzione Linux non dispone ancora degli ultimi aggiornamenti del kernel Linux, ti consigliamo vivamente di cambiare subito la tua distribuzione Linux.

Controlla le vulnerabilità di Meltdown e Spectre

Su Arch Linux e derivati, puoi scoprire se il tuo sistema è interessato da vulnerabilità di fusione/spettro usando i seguenti due comandi.

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
$ dmesg | grep iso

Se i comandi precedenti non restituiscono NIENTE, il tuo sistema non è ancora aggiornato. Quindi, devi aggiornare il tuo sistema basato su Arch usando il comando:

$ sudo pacman -Syu

Dopo aver aggiornato completamente il tuo sistema Arch, riavvia ed esegui nuovamente i comandi precedenti. Se il tuo sistema è patchato, dovresti vedere il seguente output per il primo comando:

CONFIG_PAGE_TABLE_ISOLATION=y

E otterrai questo output per il secondo comando.

[ 0.000000] Kernel/User page tables isolation: enabled

Ho già aggiornato il kernel nel mio sistema Arch. Come puoi vedere nell'output sopra, il mio kernel Linux è 4.14.12-1-ARCH ed è già patchato. Se non hai ancora aggiornato il tuo sistema Arch, non otterrai alcun output.

I comandi precedenti potrebbero non funzionare in Ubuntu. Per fortuna, alcuni bravi samaritani su Askubuntu forum ha pubblicato una soluzione alternativa per scoprire se i tuoi sistemi Ubuntu sono stati aggiornati o meno utilizzando uno dei seguenti comandi.

$ 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 :("

Se l'output è senza patch , il tuo sistema non è ancora aggiornato. Aggiorna immediatamente il kernel per applicare le patch.

Uso ancora 4.4.0-104-generico nel mio sistema Ubuntu, quindi vengo "senza patch" nel risultato di tutti i comandi.

Vai ad aggiornare il tuo kernel immediatamente usando il comando:

$ sudo apt-get update
$ sudo apt-get dist-upgrade

Oppure, come descritto nel seguente link.

  • Utilità del kernel Linux:script per compilare e aggiornare il kernel Linux più recente per Debian e derivati

Dopo aver aggiornato il kernel, esegui di nuovo quei tre comandi e vedrai che il tuo sistema Ubuntu è patchato!

Per altre distribuzioni Linux, esiste uno script chiamato "Spectre &Meltdown Checker" per verificare le vulnerabilità di Meltdown/Spectre. Questo script ti aiuterà a scoprire se la tua installazione Linux è vulnerabile contro i 3 CVE di "esecuzione speculativa".

Git clona questo script:

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

Questo clonerà tutti i contenuti in una directory denominata "spectre-meltdown-checker" nella directory di lavoro corrente.

Vai a quella directory:

$ cd spectre-meltdown-checker/

Rendi eseguibile lo script:

$ chmod +x spectre-meltdown-checker.sh

Infine eseguilo per trovare le vulnerabilità:

$ sudo ./spectre-meltdown-checker.sh

Ecco l'output di esempio dal mio sistema Ubuntu patchato:

Senza opzioni, ispezionerà il kernel attualmente in esecuzione. Puoi anche specificare un'immagine del kernel sulla riga di comando, se desideri ispezionare un kernel che non stai eseguendo.

Aggiornamento:

Lo script spectre-meltdown-checker è disponibile nei repository ufficiali di alcune distribuzioni Linux.

Su Debian, Ubuntu:

$ sudo apt install spectre-meltdown-checker

Su CentOS, RHEL:

$ sudo yum install epel-release
$ sudo yum install spectre-meltdown-checker

Su Fedora:

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

Dopo aver installato spectre-meltdown-checker, eseguilo come utente root o con privilegi sudo per verificare la presenza di vulnerabilità di Spectre e Meltdown:

$ sudo spectre-meltdown-checker

Risultato di esempio:

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

Come puoi vedere nell'output sopra, i problemi di Spectre e Meltdown non sono ancora stati corretti.

Corregge le vulnerabilità relative a Meltdown e Spectre

Come ho già detto, si consiglia vivamente di mantenere aggiornati il ​​kernel, il sistema e tutto il software, poiché sono disponibili anche molte altre correzioni di sicurezza.

Per aggiornare/aggiornare Arch Linux, esegui:

$ sudo pacman -Syu

Per aggiornare Debian, Ubuntu:

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

Per aggiornare Fedora:

$ sudo dnf update

Per aggiornare RHEL/CentOS:

$ sudo yum update

Dopo aver aggiornato il tuo sistema Linux, non dimenticare di riavviarlo.

Ancora una volta, ricorda che questi problemi non sono ancora stati completamente risolti. Devi continuare ad aggiornare i tuoi sistemi Linux nelle prossime settimane, finché tutto non sarà risolto.

Lettura consigliata:

  • Come rendere il sistema Linux più veloce su CPU Intel

Linux
  1. Come verificare la presenza di porte aperte in Linux con netstat, lsof e nmap

  2. Come controllare la versione del sistema operativo e di Linux

  3. Come salvare i comandi Linux e usarli su richiesta

  4. Linux:come verificare che una distribuzione Linux sia sicura e non abbia codice dannoso??

  5. Come mitigare le vulnerabilità Spectre e Meltdown sui sistemi Linux?

Diversi tipi di kernel per Arch Linux e come usarli

Come controllare la cronologia di riavvio del sistema e il tempo di avvio in Linux

Come controllare la dimensione di file e directory su Linux

Permessi della directory Linux di base e come controllarli

Tipi di base di utenti Linux e come controllarli

Come installare e configurare il sottosistema Windows per Linux