Archivi categoria: spectre

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.

Nuovi orizzonti per difendersi da Meltdown e Spectre, ecco LKRG, protettore del Kernel Linux!

Facebooktwittergoogle_plusredditlinkedin

Mitigare o non mitigare. Dopo Meltdown e Spectre è questo il problema, ma come diciamo da tempo c’è tutto uno spettro di possibilità di attacco ancora inesplorate che diventeranno attualità da un giorno con l’altro.

E’ per questo che suona positiva la notizia riportata dal team LKRG che ha reso pubblica la prima release del progetto, la 0.0, disponibile per il download.

Nato nel 2011, quindi a dispetto di quel 0.0 del numero di release non certo un progetto giovane, LKRG si pone come una guardia operativa dei processi eseguiti dal Kernel. Di fatto si tratta di un modulo vero e proprio che effettua controlli di integrità del Kernel Linux e rileva vulnerabilità di sicurezza ed exploit contro lo stesso.

La volontà dei creatori è quella di rilevare gli attacchi ed agire mentre il Kernel è in esecuzione e quando vengono stabilite e verificate le credenziali di accesso.

Certo, come descrive questo articolo di bleepingcomputer.com  il modulo ha un paio di svantaggi decisamente pesanti:

  1. Come gli stessi creatori del progetto affermano, trattandosi di un modulo, LKRG è bypassabile per design, e quindi ha dei limiti impliciti di utilizzo;
  2. L’impatto sulle performance è piuttosto consistente, 6,5%. Anche se gli sviluppatori hanno già avvertito che tale dato andrà a ridursi man mano che lo sviluppo evolverà;

Insomma, una soluzione imperfetta le cui potenzialità però risultano parecchie, ma visti i tempi che corrono è sicuramente un buon passo avanti per sentirsi più protetti.

Patch Meltdown e Specter: performance non così pessime

Facebooktwittergoogle_plusredditlinkedin

Con il rush dello scorso mese, tutti bene o male abbiamo deciso di patchare i nostri sistemi per evitare le vulnerabilità -o almeno quelle scoperte fino ad oggi- relative a Spectre e Meltdown.

Una delle note più negative che tutti abbiamo dovuto valutare era un presunto calo delle performance dei nostri sistemi variabile in media dal 2% al 19% a seconda del tipo di attività.

Quanto riportato però da Greg Kroah-Hartman, responsabile del branch stable del kernel, relativamente alla release 4.15 del kernel (la prima completamente patchata per i due bug), è però una situazione un pochino meno pessima di quanto ci si aspettasse:

From an email thread forwarded to me about one Linux user benchmarking recent kernel versions on a specific network-heavy load:

“4.15 is 7-9% faster than 4.11”
“Turning kpti on makes 4.15 1-2% slower than 4.11”

So, overall, we are right back where we started from. Which makes me feel good, the recent Meltdown changes turn out to not really be much of a problem overall.

Da un thread di email che mi è stato inoltrato un utente Linux che ha fatto dei benchmark sulle recenti versioni del kernel su un carico di rete molto pesante:

“4.15 è più veloce del 7-9% rispetto al 4.11”
“Attivare il kpti rende il 4.15 l’1-2% più lento rispetto al 4.11”

Quindi, in generale, siamo tornati al punto di partenza. Il che mi fa stare bene, i recenti cambiamenti per Meltdown sono risultati non essere un grosso problema in generale.

Nel frattempo, Michael Larabell, principale autore e benchmarker del famoso sito Phoronix, in alcuni test recenti sui kernel dal 4.0 al 4.15 ha decreato quanto segue:

There are some slowdowns when using the Linux 4.15 kernel … at least in several of the real-world benchmarks, the performance out of Linux 4.15 is fortunately not at the lowest levels we’ve seen with benchmarking these kernel releases of the past three years

Ci sono alcuni rallentamenti durante l’utilizzo del kernel Linux 4.15… in alcuni benchmark nel mondo reale [ndt. su macchine realmente usate], le performance rilevate su Linux 4.15 non sono fortunatamente ai livelli più bassi dei benchmark che abbiamo rilevato nelle release del kernel dei passati 3 anni

Buone notizie, quindi, un calo di performance c’è stato, ma sicuramente niente di così grave da causare grossi problemi sulle macchine di produzione che quotidianamente utilizziamo, sia come amministratori che come utenti. Ovviamente una precisazione, fatta sempre dal buon Greg Kroah-Hartman è necessaria:

But if you are stuck at an old kernel version (i.e. 3.10.y, 4.4.y, or 4.9.y or whatever your distro is camping on for the next decade), that’s a totally different story. Go forth and benchmark! Then go update to a newer kernel version, odds are it will be a good improvement.

Ma se siete bloccati su una vecchia versione del kernel (es: 3.10.y, 4.4.y o 4.9.y o su qualsiasi la vostra distribuzione continuerà a campare per il prossimo decennio), è un discorso completamente differente. Andate e fate i benchmark! Poi andate ed aggiornate ad una nuova versione del kernel, molto probabilmente sarà un bel miglioramento.

Quindi alla fine ritorniamo sempre allo stesso punto: aggiornate gente.

Noi lo abbiamo fatto e siamo soppravvisuti, e voi?