Archivi categoria: spectre

Red Hat rende OpenSource lo scanner per eseguibili potenzialmente veicolo di Spectre

Facebooktwittergoogle_plusredditlinkedin

Red Hat ha reso disponibile uno strumento di analisi in grado di identificare potenziali attacchi volti a sfruttare la arcinota vulnerabilità Spectre (precisamente la variante 1 di Spectre) all’interno di file binari.

La modalità con cui l’eseguibile può essere invocato è semplice:

x86_64-scanner vmlinux --start-address=0xffffffff81700001

ed il risultato potrà essere un rassicurante:

X86 Scanner: No sequences found.

O un ben più preoccupante esito positivo:

X86 Scanner: Possible sequence found, based on a starting address of 0:.
X86 Scanner: 000000: nop.
X86 Scanner: COND: 000001: jne &0xe .
X86 Scanner: 00000e: jne &0x24 .
X86 Scanner: LOAD: 000010: mov 0xb0(%rdi),%rcx.
X86 Scanner: 000017: mov 0xb0(%rsp),%rax.
X86 Scanner: 00001f: nop.
X86 Scanner: LOAD: 000020: mov 0x30(%rcx),%rbx.

Inutile dire come il livello di competenze necessario per concepire anche solo lo scan del file stesso (in questo esempio è stato analizzato proprio il kernel stesso, vmlinux, l’eseguibile che diventerà pid 0 all’interno del sistema) sia decisamente elevato, ma nulla vieta di poter replicare gli esempi forniti.

Più importante di tutto il resto: il tool in questione è stato rilasciato in forma open-source, perciò chiunque può analizzarne il codice e, con molta pazienza e competenza, carpire un po’ di più in merito a questa fastidiosa vulnerabilità.

Curiosi su come fare? Ecco un piccolo how-to basato su Fedora 28:

Per prima è necessario scaricare e decomprimere il file scanner:

$ wget https://people.redhat.com/~nickc/Spectre_Scanner/scanner.tar.xz
$ tar -xJf scanner.tar.xz
$ cd scanner

A questo punto, nel sistema andrà installato il pacchetto binutils-devel, necessario alla compilazione del sorgente:

$ sudo dnf install binutils-devel

E scaricati i sorgenti dello stesso pacchetto, poiché alcune librerie necessarie non sono presenti nel pacchetto devel:

$ wget https://ftp.gnu.org/gnu/binutils/binutils-2.29.1.tar.xz
$ tar -xJf binutils-2.29.1.tar.xz

Quindi, prima di lanciare il fantomatico comando make, all’interno del file makefile andranno impostate le seguenti variabili:

all: x86_64-scanner
...
...
...
# If you are building the tool in a separate directory
# to the sources, then you will need to add a path to
# the scanner.h header file.
#CFLAGS += -I /path/to/scanner/sources
CFLAGS += -I /home/rasca/scanner

# The scanner uses some header files that are part of
# the binutils sources, but which are not normally
# distributed with binary packages. (eg elf/internal.h)
# You can get the binutils sources from:
# https://ftp.gnu.org/gnu/binutils/
#CFLAGS += -I /path/to/binutils/sources/include
CFLAGS += -I /home/rasca/scanner/binutils-2.29.1/include

Dove chiaramente /home/rasca andrà sostituito con la vostra home directory. A questo punto tutto è pronto per la compilazione:

$ make
gcc -c scanner.c -Wall -I. -O3 -I /home/rasca/scanner -I /home/rasca/scanner/binutils-2.29.1/include
gcc -c x86_64-scanner.c -Wall -I. -O3 -I /home/rasca/scanner -I /home/rasca/scanner/binutils-2.29.1/include
gcc scanner.o x86_64-scanner.o -o x86_64-scanner -lopcodes -lbfd -liberty -lm -lz -ldl

L’esempio riportato all’inizio si preoccupava di analizzare un file denominato vmlinux, ossia il kernel del sistema, per fare lo stesso sarà necessario copiare il proprio kernel nella directory locale e decomprimerlo in modo da ottenere il file vmlinux (se siete curiosi sul perché di questi comandi a questo link si trova un’esauriente spiegazione):

$ wget -O extract-vmlinux https://raw.githubusercontent.com/torvalds/linux/master/scripts/extract-vmlinux
$ chmod +x extract-vmlinux
$ ./extract-vmlinux vmlinuz-4.17.6-200.fc28.x86_64 > vmlinux

Sarà possibile eseguire infine lo scanner:

$ ./x86_64-scanner vmlinux --start-address=0xffffffff81700001
X86 Scanner: No sequences found.

In questo caso il kernel non presenta vulnerabilità. Per fortuna, aggiungerei 🙂

È tutto, buona verifica!

Altre grane per i processori: ecco Spectre 1.1 e 1.2

Facebooktwittergoogle_plusredditlinkedin

Le nuove vulnerabilità sfruttano lo stesso principio di Metldown e Spectre, ma permettono diversi tipi di attacchi alle CPU. La sensazione che molti hanno avuto al momento della scoperta di Meltdown e Spectre è confermata: l’emersione delle due vulnerabilità nelle CPU era solo il primo capitolo di una saga che promette di continuare a lungo. […]

L’articolo Altre grane per i processori: ecco Spectre 1.1 e 1.2 proviene da Securityinfo.it.

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.