Archivi categoria: spectre

Kernel Linux: arrivano le prime patch per Spectre V4

Facebooktwittergoogle_plusredditlinkedin

Risale già a qualche settimana fa la scoperta di una nuova falla della serie Meltdown/Spectre da parte dei team di Microsoft e Google ed arrivano anche le prime mitigation nel kernel Linux.

La versione 4.17 rilasciata negli scorsi giorni infatti include anche diverse patch per arginare i problemi che hanno introdotto Spectre e Meltdown:

  • Fix per alcune CPU x86 di produzione cinese;
  • Fix per Spectre per IBM s390;
  • Fix per Spectre V4 per Power7, Power8 e Power9;
  • Fix per Spectre V4 su CPU Intel.

Per il kernel 4.18 sono previste ulteriori patch per mitigare i problemi derivanti dallo Speculative Store Bypass stavolta sulle CPU di AMD che utilizzeranno le direttive SPEC_CTRL / VIRT_SPEC MSR che verranno fornite in futuro dal produttore insieme agli aggiornamenti firmware.

Al momento, questa sembrerebbe anche l’unica mitigation inclusa nel kernel 4.18 che fa riferimento all’architettura x86. Oltre a questa, infatti, sono previsti aggiustamenti anche per Spectre V4 su ARM64 e, finalmente, per Spectre V1/V2 su ARM 32-bit.

Vedremo mai la fine di questa neverending “apply-fix-and-reboot-you-machine” story?

Spectre next generation: rivelate otto nuove vulnerabilità nei processori Intel

Facebooktwittergoogle_plusredditlinkedin

I toni sono piuttosto catastrofici, ma purtroppo lo si sapeva già, o quantomeno ce lo si aspettava: altre falle di tipo Spectre sono state esposte. Sembrerebbero addirittura otto le nuove falle scoperte ed evidenziate da Heise, una rivista tedesca di computer, in questo articolo. Intel ha assegnato la categoria “high” a quattro di queste e quella “medium” alle altre quattro. Il risultato per l’utente finale? C’è poco da stare allegri e soprattutto c’è da prepararsi ad un nuovo giro di update che presto o tardi colpirà tutti.

I piani di Intel sono quelli di rilasciare le patch per questi problemi in due trance: la prima a maggio 2018 (quindi, uhm, oggi), la seconda ad agosto 2018.

Quindi, in attesa di tutto questo, facciamo un piccolo punto della situazione: è possibile conoscere lo stato del proprio sistema in merito a Meltdown e Spectre mediante il filesystem virtuale /sys. È sufficiente lanciare questo comando:

grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW

L’output del comando è stato copiato da un sistema Fedora 27, aggiornata alle ultime patch disponibili, ma lo stesso può essere utilizzato su qualsiasi sistema Linux aggiornato per capire il livello di (in)sicurezza a cui si è sottoposti. Da notare come nel caso illustrato Spectre v2 venga attenuato da retpoline.

Più giù di così non si può? No, non ancora, anche se è facile presumere cosa c’è dietro l’angolo: nuovi falle saranno scoperte e nuovi giri di patch saranno necessari. Il che significa davvero un’enorme mole di lavoro per chi gestisce i datacenter e la sicurezza in generale.

Rimbocchiamoci le maniche!

Reptoline, la via di Google per sanare Spectre nei Kernel Linux già disponibile su RedHat

Facebooktwittergoogle_plusredditlinkedin

Le mitigation introdotte dalle varie distribuzioni per risolvere i problemi di sicurezza derivanti dalle falle Spectre e Meltdown non stanno funzionando a dovere. Nessuna novità in questo, ma tra problemi di performance o copertura limitata, ad esempio alcune esclusioni sui processori AMD64, l’impressione è che ci sia ancora molto da lavorare.

Con l’introduzione di Retpolines Google ha cercato di tagliare la testa al toro, facendo in modo che il Kernel abbia il totale controllo sulle esecuzioni speculative (vera causa del disastro) . L’approccio di Google oltre che essere più veloce è anche molto più generico rispetto alle specifiche patch del microcode di Intel, offre quindi una migliore copertura e vien da se che si possa definire una soluzione superiore.

Ebbene, alla luce di tutto questo, Red Hat ha messo a disposizione diverse analisi sulle performance nelle quali viene evidenziata la valenza dell’approccio Reptoline su diversi tipi di carico e ambito di utilizzo. In ogni caso l’approccio retpoline dimezza essenzialmente l’impatto sulle performance.

Come testare tutto questo? Anche in questo caso Red Hat ha reso disponibile una dettagliata pagina di istruzioni che descrive dalla A alla Z cosa è necessario fare, quali CVE sono coinvolti e, addirittura, come automatizzare l’operatività delle patch mediante profili tuned.

Non resta che mettersi al lavoro!

Intel: il prossimo chip sarà completamente protetto da Spectre e Meltdown

Facebooktwittergoogle_plusredditlinkedin

Qualche giorno fa la californiana Intel, nell’occhio del ciclone da inizio anno per Spectre/Meltdown, ha annunciato che i nuovi chip saranno completamente protetti da queste vulnerabilità.

E’ noto che, nonostante patch siano state sviluppate ed oramai disponibili per -quasi- tutti i sistemi operativi, queste vulnerabilità sono hardware e che, quindi, per quanto una patch software possa sopperire ad alcuni problemi, non c’è modo alcuno di risolverli completamente, se non sostituendo il chip stesso.

Nonostante l’azienda sia ancora al lavoro per supportare lo sviluppo di patch per tutti i suoi processori degli ultimi due decenni, in questi giorni ha annunciato che la prossima generazione di chip che produrrà utilizzeranno un metodo chiamato “partitioning” (partizionamento) che permetterà di proteggerli da problemi similari in futuro, inframezzandosi tra il livelo dei privilegi e lo user space.

We have redesigned parts of the processor to introduce new levels of protection through partitioning that will protect against both Variants 2 and 3. Think of this partitioning as additional “protective walls” between applications and user privilege levels to create an obstacle for bad actors.

Abbiamo riprogettato parti del processore per introdurre nuovi livelli di protezione tramite partizionamento, che proteggerà da entrambi le Varianti 2 e 3. Si può pensare a questo partizionamento come a dei “muri di protezione” aggiuntivi tra le applicazioni ed i livelli di privilegi utente, andando a creare un ostacolo per i malintenzionati.

Questo quanto affermato da Brian Krzanich, CEO della Intel Corporation, confermando anche che l’ottava release dei loro processori Intel Core avverrà nella seconda metà del 2018, insieme ai nuovi processori Intel Xeon Scalable “Cascade Lake”, che conterranno lo stesso metodo di partizionamento.

Avremo quindi la possibilità di acquistare hardware totalmente libero da questi problemi, anche se il fatto che l’aggiornamento richiede investimento monetario, invece dei soliti giri di update su yum/apt, fa pensare che i processori fallati saranno in giro ancora per molto tempo.

Voi aggiornerete l’hardware o siete confidenti nelle patch software che già avete?

Spectre e Meltdown sono solo sensazionalismo?

Facebooktwittergoogle_plusredditlinkedin

L’inizio dell’anno è stato sicuramente dominato dal caso Spectre e Meltdown: annunciato al pubblico l’ultima settimana del 2017, ha causato delle correzioni da applicare a tutti i sistemi operativi; l’essere un bug hardware, e pure diffuso tra varie piattaforme (Intel ed AMD, x86 ed ARM), implicava che nessuno era al sicuro.

Ma forse tutta questa furia non era giustificata. O meglio: il bug è sicuramente presente, e le conseguenze sono accertate, ma è la pericolosità effettiva da dover essere rivalutata. O almeno questo è quanto sostiene Hugh Darvall, direttore delle vendite di Flexera (società software Americana che produce anche InstallShield), in un post intitolato -non a caso- come questo: “Are Spectre and Meltdown just hype?”

Il post è breve, ed incentrato su una considerazione:

Through Secunia Research at Flexera, more than 121 vulnerability intelligence advisories were issued on Spectre and Meltdown. However, most advisories were scored below “Moderately Critical” (one to three out of a maximum score of five). As a matter of fact, 5 advisories scored “Highly Critical” (four out of five).

To put this in perspective, Secunia Research issued another 52 unrelated advisories scored “Highly Critical” in the two weeks following the public disclosure of Meltdown and Spectre. The vulnerabilities were found in widely used software.

Tramite Secunia Research, di Flexera, sono stati esposti più di 121 avvisi di vulnerabilità delle informazioni riguardanti Spectre e Meltdown. Tuttavia, molti degli avvisi avevano punteggio sotto il “Moderatamente Critico” (da 1 a 3 su una scala di massimo 5). Per dovere di cronaca, 5 avvisi erano “Altamente Critici” (4 su 5).

Per mettere la cosa in prospettiva, Secunia Resarch ha esposto altri 52 avvisi non correlati di livello “Altamente Critico” nelle due settimane seguenti l’annuncio al pubblico di Meltdown e Spectre. Le vulnerabilità sono state trovate in software di largo uso.

Quindi, il clamore mediatico è stato eccessivo, ma soprattutto la fretta – o la furia – per scrivere e rilasciare le patch non erano giustificate: il pericolo è (ed era) tutto sommato basso, o almeno non eccezionale.

L’articolo procede quindi a spiegare i tre passi da seguire per essere efficaci nell’affrontare un problema di sicurezza, soprattutto in ambito enterprise:

  1. identificare i pericoli con spirito critico, valutando anche la fonte delle informazioni; identificare quindi la vulnerabilità maggiore, su cui concentrarsi
  2. non cedere all’ansia e creare delle priorità;
  3. approccio conservativo: applicare le patch in ambiente controllato, su un numero limitato di macchine di cui valutare le prestazioni pre e post. Questo serve anche per sapere se la patch non introduce problemi maggiori di quello che deve essere risolto…

E voi, cosa ne pensate?

Intel e la diffusione di notizie “pratica” di Spectre e Meltdown

Facebooktwittergoogle_plusredditlinkedin

Di come Intel non abbia gestito al meglio la situazione scatenata dalla scoperta delle falle note come Meltdown e Spectre abbiamo parlato parecchio.

Molte sono state le critiche, che vanno dal ritardo rispetto ai 90 giorni previsti dal Project Zero di Google (che avvisò Intel della falla a Giugno dell’anno scorso), fino a teorie più complottiste nate dalla vendita, da parte del CEO di Intel Brian Krzanich, di azioni societarie per oltre 39 milioni di dollari prima del rilascio pubblico di informazioni riguardo la falla.

Quello che è certo è che Intel ha deciso di attuare un processo molto più pratico di quanto ci si aspettasse: dovendo necessariamente avvisare qualcuno di quanto stava succedendo, ha deciso di avvisare solo gli attori che avrebbero potuto dare una mano a mitigare la larga diffusione di problemi riguardandi i due bug, facendo enforcing di sicurezza.

“I sette”, così vengono chiamate le aziende che erano a conoscenza dei bug, sono decisamente noti: si parte da Intel stessa, seguita da Amazon, AMD, Apple, ARM, Google e Microsoft.

Oltre ad una prima decisione da parte di questi di rilasciare pubblicamente informazioni a Gennaio, pur sforando i classici 90 giorni al fine di avere più tempo per preparare dei fix, la parte critica è che tra gli enti avvisati mancano completamente il Governo degli Stati Uniti così come il CERT (Computer Emergency Readiness Team) degli stessi.

Ora, a seguito di questo comportamento il congresso Americano ha richiesto spiegazioni ad Intel, rese pubbliche in questa lettera che mostra l’approccio:

Before the leak, Intel disclosed information about Spectre and Meltdown only to companies who could assist Intel in enhancing the security of technology users.

Prima della diffusione, Intel ha condiviso le informazioni riguardo Spectre e Meltdown solo a quelle aziende che avrebbero potuto assisterla nel migliorare la sicurezza degli utenti di quella tecnologia

Molto pratico, dunque: non puoi far nulla per darmi una mano? Non hai bisogno di sapere nulla a riguardo.

Molte di queste aziende comunque hanno rilevato che il dover mantenere segreta la cosa ha creato non pochi problemi. Tra queste Microsoft, ad esempio, ha visto che le fix implementate davano problemi con alcuni software anti-virus, ha tentato di avvisare i produttori di questi ma non poteva spiegare il motivo dei cambiamenti che stava apportando e che causavano questi malfunzionamenti.

Altre si sono attivate per la community e, di riflesso, per i loro stessi interessi, come Amazon che ha:

focussed our efforts on developing countermeasures for the Linux operating system and the Xen hypervisor

concentrato il nostro effort nello sviluppo di contromisure per il sistema operativo Linux e l’hypervisor Xen

Che ha potuto dunque proteggere i suoi sistemi basati fortemente su Linux, come AWS ad esempio, pur vestendo i panni del buon samaritano con la community (e non che le due cose siano per forza mutue esclusive).

Al momento il Congresso Statuintense non ha ancora reso pubblica una risposta a questa lettera, ma possiamo solo immaginare che l’essere tenuta all’oscuro del problema gli possa solo far storcere il naso.

VMware nuova patch di sicurezza vCenter Server 6.5 U1f

Facebooktwittergoogle_plusredditlinkedin

VMware nuova patch di sicurezza vCenter Server 6.5 U1f

vmware-new-security-patch-vcenter-server-65u1f-01

VMware ha rilasciato una nuova patch di sicurezza per il sistema operativo Photon della vCSA – vCenter Server 6.5 U1f build number 7801515 – contro due vulnerabilità relative alle problematiche Meltdown e Spectre.

La nuova patch vCenter Server 6.5 U1f risolve le problematiche bounds-check bypass (Spectre-1, CVE-2017-5753) e rogue data cache load (Meltdown, CVE-2017-5754). Per la vulnerabilità branch target injection (Spectre-2, CVE-2017-5715) non c’è invece ancora nessuna patch.

package aggiornati sono i seguenti:

  • linux 4.4.110-2
  • libgcrypt 1.7.6-3
  • c-ares 1.12.0-2
  • ncurses 6.0-8
  • libtasn1 4.12-1
  • wget 1.18-3
  • procmail 3.22-4
  • rsync 3.1.2-4
  • apr 1.5.2-7

Anche la VMware security advisory VMSA-2018-0007.1 è stata aggiornata con tutti gli aggiornamenti delle appliance virtuali per le vulnerabilità Spectre e Meltdown e attualmente le sole patch disponibili sono per vCenter Server Appliance (6.5 U1f) e per vSphere Integrated Containers (version 1.3.1).

vmware-new-security-patch-vcenter-server-65u1f-02

 

Aggiornamento a vCenter Server 6.5 U1f

Per procedere copn l’aggiornamento della vCSA, bisogna accedere alla management console dell’appliance inserendo le credenziali corrette e cliccando su Login.

vmware-new-security-patch-vcenter-server-65u1f-03

Posizionarsi nell’area Update e cliccare sulla voce Check Updates > Check Repository per verificare la disponibilità di nuovi aggiornamenti.

vmware-new-security-patch-vcenter-server-65u1f-04

Quando il nuovo aggiornamento viene rilevato, cliccare su Install > Install All Updates per procedere con l’aggiornamento.

vmware-new-security-patch-vcenter-server-65u1f-05

Cliccare su Accept per accettare l’EULA.

vmware-new-security-patch-vcenter-server-65u1f-06

Cliccare Install per avviare l’installazione.

vmware-new-security-patch-vcenter-server-65u1f-07

La patch viene installata nella vCSA.

vmware-new-security-patch-vcenter-server-65u1f-08

Quando l’installazione viene completata correttamente, cliccare su OK per riavviare l’appliance.

vmware-new-security-patch-vcenter-server-65u1f-09

L’appliance si riavvia per applicare gli aggiornamenti.

vmware-new-security-patch-vcenter-server-65u1f-10

Dopo che la vCSA ha terminato il reboot, il processo di patching è completo. La build number viene ora indicata come 7801515.

vmware-new-security-patch-vcenter-server-65u1f-11

L’aggiornamento è al momento disponibile solo dal repository.

signature

Copyright Nolabnoparty. All Rights Reserved.

FreeBSD finalmente patchato per Spectre / Meltdown

Facebooktwittergoogle_plusredditlinkedin

Seppur con qualche settimana di ritardo, anche su FreeBSD arrivano le mitigation per Spectre e Meltdown.

Sono presenti le patch Meltdown per le CPU Intel tramite un’implementazione KPTI (Kernel Page Table Isolation) simile a quella utilizzata dalle altre distro Linux. È presente inoltre l’ottimizzazione PCID (Process Context Identifier) per le CPU Intel Westmere e successive.

Per quanto riguarda Spectre, viene applicata la IBRS (Indirect Branch Restricted Speculation) per arginare i problemi causati dalla Variante 2 di questa falla.

Le patch sono disponibili sui repository SVN e sono stati assegnati alla versione 11 (stable). Al momento una release di FreeBSD che includa direttamente le patch non esiste.

La versione 11.2 di FreeBSD è schedulata per il rilascio il 27 giugno, anche se a questo punto non si escludono variazioni sulla data di pubblicazione.