Archivi categoria: meltdown

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.

Anche OpenBSD riceve le patch per Meltdown

Facebooktwittergoogle_plusredditlinkedin

Quando ad inizio anno c’è stato il rush di aggiornamenti per Meltdown sui vari OS, parecchi sistemi BSD sono rimasti indietro.

Tra i sistemi Unix-like come – appunto – BSD, sicuramente il fatto di avere una base utente molto più limitata rispetto ad altre controparti (leggi Linux) ha penalizzato molto l’arrivo di queste patch, sia per una disponibilità molto minore di sviluppatori che per una base utente di test molto ridotta.

Qualche giorno fa vi avevamo parlato dell’arrivo delle patch per Meltdown su FreeBSD, che seppur non sia stato il primo di quella famiglia a riceverle (il primo BSD fu DrabgoFlyBSD che le ricevette il 5 Gennaio), sicuramente è uno dei sistemi Berkeley Software Distribution più utilizzati.

Finalmente anche il fratello OpenBSD, famoso per essere tra i più sicuri della famiglia, riceve queste patch disponibili da ieri, come si evince da un commit nel kernel da parte dello sviluppatore Philip Guenther:

When a syscall, trap, or interrupt takes a CPU from userspace to kernel the trampoline code switches page tables, switches stacks to the thread’s real kernel stack, then copies over the necessary bits from the trampoline stack. On return to userspace the opposite occurs: recreate the iretq frame on the trampoline stack, switch stack, switch page tables, and return to userspace.

Quando una syscall, una trap o un interrupt porta la CPU da userspace al kernel, il codice trampolino scambia le tabelle delle pagine, girando lo stack sul reale thread nel kernel, dopodichè copia i bit necessari dallo stack trampolino. Nel ritorno allo userspace, avviene l’inverso: viene ricreato il frame iretq sullo stack trampolino, vengono girati gli stack, scambiate le tabelle delle pagine e si ritorna allo userspace.

Tecnicismi a parte, in soldoni viene utilizzato uno stack intermedio (chiamato trampolino) per il passaggio dei dati, assicurandosi che questo avvenga solo al cambio di contesto, e mitigando quindi l’applicazione delle vulnerabilità che sfruttano Meltdown.

Su diversi forum e sistemi di commenti impazza la discussione che vede due parti contrapporsi: la prima, valutando il fatto che gli sviluppatori BSD siano venuti a conoscenza di questi bug solo da inizio Gennaio (mentre pare che le discussioni su eventuali mitigation nel kernel Linux siano partite diverse settimane prima) denoti la rapidità del fixing da parte di quegli OS, mentre la seconda sostiene che il fatto di avere patch ad inizio Gennaio per tutti gli OS e vedere i BSD arrivarci solo a fine Febbraio indichi sostanzialmente che la forza lavoro su quegli OS sia decisamente ridotta e poco reattiva.

L’importante è avere le patch, alla fine dei conti, ma ci domandiamo: questo ritardo può pilotare la scelta di uno o l’altro OS per ambienti in cui effettivamente avrebbero senso entrambi?

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?

Kernel 4.15: il primo completamente patchato contro Meltdown e Spectre

Facebooktwittergoogle_plusredditlinkedin

After a release cycle that was unusual in so many (bad) ways, this last week was really pleasant. No last-minute panics, just small fixes for various issues. I never got a feeling that I’d need to extend things by yet another week, and 4.15 looks fine to me.

Dopo un ciclo di rilascio inusuale sotto molti (brutti) aspetti, la scorsa settimana è stata molto piacevole. Niente problemi dell’ultimo minuto, solo piccoli fix per alcuni problemi. Non ho avuto la sensazione di dover attendere un’altra settimana, il 4.15 mi sembra a posto.

Con questo messaggio Linus Torvalds annuncia finalmente il rilascio del kernel 4.15, una release che ha richiesto un lungo ciclo di sviluppo, tanto da arrivare alla RC9, cosa che non succedeva dal 2011.

Le difficoltà erano ovviamente dovute al caos Meldown/Spectre, bug hardware che affligge tutte le CPU degli ultimi 20 anni circa. Il kernel 4.15 inaugura una nuova era di kernel che saranno completamente patchati contro i due bug… per chi utilizza CPU x86 e PowerPC. Bene, ma non benissimo diciamo.

Torvalds ribadisce comunque che “non è finita”: mancano ancora i fix per ARM e per la variante 1 di Spectre.

Oltre alle patch per queste vulnerabilità, questa release introduce diverse novità:

  • supporto ad architetture RISC-V;
  • supporto ad AMD SEV (Secure Encripted Virtualization)
  • supporto UNIP (User-Mode Instruction Prevention), per CPU Intel
  • supporto video migliorato e nuove feature per i driver open-source AMDGPU
  • miglioramento del risparmio energetico con l’utilizzo del SATA link power management

Il kernel 4.15 è già disponibile al download, mentre sarà necessario ancora qualche tempo (come sempre) prima che venga rilasciato nei repository ufficiali delle varie distibuzioni.