Come attenuare la vulnerabilità SRBDS (CVE-2020-0543) senza riavviare il server
Recentemente, gli accademici del Systems and Network Security Group (VUSec) dell'Università di Vrije 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 far 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.
Che cos'è CrossTalk?
La vulnerabilità CrossTalk è un tipo di attacco MDS (microarchitectural data sampling), simile a 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. Nominato come \CVE-2020-0543) da Intel, consente l'esecuzione di codice controllato dagli aggressori su un core della CPU, il che si traduce nella perdita di dati sensibili dal software della vittima in esecuzione su un core diverso.
Qualsiasi sistema che utilizza una CPU Intel può essere interessato da questa vulnerabilità. Controlla qui se la tua CPU è interessata.
Mitigazione senza riavvio della vulnerabilità SRBDS (CVE-2020-0543)
Intel ha implementato la 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 dell'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 amministratore di sistema che si occupa di oltre 500 server, lo è sicuramente. Il riavvio di un'intera flotta di server di solito richiede un'attenta pianificazione della finestra di manutenzione. Fortunatamente, la tecnologia di patch live consente di applicare gli aggiornamenti di sicurezza ai sistemi contro CrossTalk senza riavviare, sia per l'aggiornamento del microcodice che per l'applicazione della 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 riavviare, nel caso di SRBDS/CrossTalk è comunque necessario riavviare un desktop o un server dopo l'aggiornamento.
Il team 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 qui sotto:
A) Se stai utilizzando l'hardware, segui 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 può essere utilizzato gratuitamente per 30 giorni su tutti i tuoi server, nessuna carta di credito richiesta per le organizzazioni sanitarie per il resto del 2020 e per sempre gratuito per le organizzazioni senza scopo di lucro.
Passaggio 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 di 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 il microcodice più recente aggiornando il pacchetto microcode_ctl
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. Eseguire 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 <>, 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
Passaggio 3: applicare le patch KernelCare
Ora devi aggiornare il kernel Linux per assicurarti che l'utente locale non possa leggere i dati che stai eseguendo sulla CPU. Con KernelCare puoi farlo senza riavviare. Se ti sei registrato per la prova al passaggio 1, sei a posto e non devi fare altro.
B) Se stai utilizzando una VM:
Devi solo applicare la patch al 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 dovrai fare altro. In caso contrario, registrati per una prova gratuita di 30 giorni.