Recentemente, accademici del Systems and Network Security Group (VUSec) della Vrije University hanno pubblicato dettagli sulla vulnerabilità CrossTalk o SRBDS (CVE-2020-0543) nei processori Intel. La vulnerabilità CrossTalk consente al codice controllato da un utente malintenzionato in esecuzione su un core della CPU di trapelare dati sensibili da altri software in esecuzione su un core diverso. In questo articolo, ti mostreremo come mitigare questa vulnerabilità della CPU Intel senza riavviare il server.
Cos'è CrossTalk?
La vulnerabilità CrossTalk è un tipo di attacco MDS (microarchitectural data sampling), simile a Spectre, Meltdown o Zombieload. Consente l'esposizione e il furto di dati sensibili mentre la macchina vi accede. Gli attacchi MDS prendono di mira i dati dell'utente mentre si trovano in uno stato transitorio, poiché risiedono all'interno della CPU e di molti sistemi ad essa collegati.
La vulnerabilità SRBDS/CrossTalk è una vulnerabilità di esecuzione transitoria. Denominato "Special Register Buffer Data Sampling" o SRBDS (CVE-2020-0543) da Intel, consente l'esecuzione di codice controllato da un utente malintenzionato su un core della CPU che provoca la fuga di dati sensibili dal software della vittima in esecuzione su un core diverso.
Figura 1:Progettazione della fase di profilazione delle istruzioni di CrossTalk, per gentile concessione di VUSec
Qualsiasi sistema che utilizza una CPU Intel potrebbe essere interessato da questa vulnerabilità. Controlla qui se la tua CPU è interessata.
Vulnerabilità Rebootless Mitigation of SRBDS (CVE-2020-0543)
Intel ha implementato la sua mitigazione per la vulnerabilità SRBDS in un aggiornamento del microcodice distribuito ai fornitori di software martedì 9 giugno 2020. Questa mitigazione richiede l'installazione delle ultime patch del kernel Linux e aggiornamento del microcodice. Entrambe le operazioni vengono tradizionalmente eseguite al riavvio.
Mentre il riavvio di un paio di server non sembra un problema, se sei un SysAdmin che si prende cura di oltre 500 server, lo è sicuramente. Il riavvio di un intero parco di server richiede solitamente una pianificazione approfondita della finestra di manutenzione. Fortunatamente, la tecnologia di patch live consente di applicare aggiornamenti di sicurezza ai sistemi contro CrossTalk senza un riavvio, sia per l'aggiornamento del microcodice che per l'applicazione di patch del kernel Linux.
Canonical, Red Hate e altri fornitori di distribuzione hanno rilasciato le patch di sicurezza per tutte le distribuzioni Ubuntu supportate, Debian, CentOS, Red Hat Enterprise Linux. E, sebbene Canonical e Red Hat abbiano la propria soluzione per correggere le vulnerabilità senza un riavvio, nel caso di SRBDS/CrossTalk è comunque necessario riavviare un desktop o un server dopo l'aggiornamento.
Il team di KernelCare ha creato una mitigazione senza riavvio per CrossTalk/SRBDS in modo da evitare di riavviare i server per applicare le patch. Trova le istruzioni di seguito:
A) Se stai utilizzando l'hardware, esegui 3 passaggi per proteggere i tuoi server dalla vulnerabilità CrossTalk/SRBDS senza riavviare:
Passaggio 1: registrati per una licenza di prova gratuita di KernelCare
KernelCare è gratuito per 30 giorni su tutti i tuoi server, nessuna carta di credito richiesta per registrarsi per una prova. È gratuito anche per le organizzazioni sanitarie per il resto del 2020 e per sempre gratuito per le organizzazioni senza scopo di lucro.
Fase 2: Aggiorna il microcodice senza riavviare
Esempio:aggiornamento del microcodice su RHEL
Questo è l'esempio di un aggiornamento del microcodice senza riavvio su RHEL. Le istruzioni per Debian, Ubuntu, CentOS e altre distribuzioni sono disponibili nella documentazione KernelCare.
Per le distribuzioni basate su RHEL, puoi utilizzare l'utilità microcode_ctl per aggiornare il microcodice.
Prima di iniziare, controlla qui se le patch per la tua distribuzione sono pronte. La pagina viene aggiornata ogni ora.
1. Ottieni l'ultimo microcodice aggiornando il microcode_ctl pacchetto
yum update microcode_ctl
2. Crea un force-late-intel–06–4f–01 all'interno della directory del firmware.
touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01
3. Esegui l'aggiornamento del microcodice
/usr/libexec/microcode_ctl/update_ucode
4. Forza il kernel a caricare il nuovo microcodice
echo 1> /sys/devices/system/cpu/microcode/reload
5. Controlla il nuovo microcodice
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
6. (Facoltativo) Ricontrolla la nuova versione del microcodice (revisioni per core)
cat /proc/cpuinfo | grep -e microcode
microcode : 0x21
microcode : 0x21
microcode : 0x21
microcode : 0x21
Fase 3:applica le patch KernelCare
Ora è necessario aggiornare il kernel Linux per assicurarsi che l'utente locale non possa leggere i dati in esecuzione sulla CPU. Con KernelCare puoi farlo senza riavviare. Se ti sei registrato per la versione di prova al passaggio 1, sei pronto e non devi fare nient'altro.
B) Se stai utilizzando una VM:
Hai solo bisogno di patchare il kernel Linux all'interno della VM. Assicurati che anche il tuo nodo host sia aggiornato, cosa che in genere viene eseguita dal tuo fornitore di servizi.
Se stai usando KernelCare, le tue patch verranno consegnate automaticamente da KernelCare e non devi fare nulla in più. In caso contrario, registrati per una prova gratuita di 30 giorni .