Re: Ancora su Spectre e Meltdown
On 13/02/2018 16:36, Portobello wrote:
per dare dei comandi alla CPU bisogna sempre passare dal
codice sorgente.
sì... e no
Quindi, ogni comando, per copiare delle zone di memoria
deve essere inserito nel codice sorgente ? (Correggetemi se sbaglio).
sì, se viene fatto un programma che permette di sfruttare questa falla.
Puoi fare qualcosa del genere (estremizzo e banalizzo):
a = 10
if( 1 == 0 )
memcpy(...)
l'istruzione memcpy non verrà mai eseguita o meglio non verrà mai
richiesta di essere eseguita, ma poiché il processore, nei momenti in
cui è idle (non sta facendo nulla o meglio è in attesa), cerca di
predire l'istruzione o le istruzioni successive e quindi di eseguirle in
anticipo. Se gli va bene ha già il risultato, se gli va male butta via
il tutto.
Se la memcpy copia da un'area di memoria non leggibile dall'user space
in cui è eseguito il programma si avrà che la lettura verrà effettuata,
verrà effettuato il controllo e verrà negato l'accesso... peccato che
nella cache della CPU ci si troverà quello che non doveva essere letto
(anche se l'istruzione è stata bloccata, ma essendo un'istruzione non
richiesta dal programma...). Ora con altre tecniche è possibile leggere
dalla cache... e quindi poter leggere ad esempio un'area di memoria dove
è stata caricata una password (certo non è così banale, però questo è
per dare un'idea).
E quindi questo è un codice scritto da un attaccante per sfruttare la
falla. Attenzione che questo codice non è detto che debba far parte di
un software installato sul proprio PC, ma potrebbe essere ad esempio
codice eseguito all'interno del browser mentre si naviga su un
determinato sito.
Però ci sono altre tecniche che permettono di prendere un codice
totalmente privo di un attacco del genere e fargli fare quello che si vuole.
Anche qui vado all'estremo opposto. Se hai accesso alla macchina puoi
usare gdb per fare il debugger di un eseguibile mentre lo esegui. A
questo punto puoi modificare le istruzioni che devono essere eseguite,
puoi modificare i valori dei registri, ... In questo modo fai eseguire
delle istruzioni che non erano presenti nel codice sorgente iniziale.
Tra i due estremi ci sono svariate casistiche.
Il problema è più grave per i software a sorgente chiuso. Perché nessuno
sa quello che c'è dentro.
questo è di sicuro vero. Infatti ci sono software non liberi che
contengono al loro interno backdoor ed altro. Quindi è più che certo che
un attaccante potrebbe distribuire un eseguibile che cela al suo interno
l'attacco e potrebbe essere molto complesso capire cosa fa.
Se non ricordo male interbase (ora conosciuto come firebird) era
proprietario e quando è stato rilasciato con licenza libera è stata
trovata nei sorgenti una backdoor[1]...
Ci sono prove che l'NSA americana ed altre agenzie premono continuamente
sui produttori di software/hardware per introdurre backdoor all'interno
dei loro prodotti e di sicuro qualcuno lo fa. In altri stati la cosa può
essere più drammatica perché si è obbligati con la forza a fare queste
azioni e si potrebbe anche rischiare il carcere o la vita se ci si
rifiuta (questo per dire che non sono gli USA il male, solo che dagli
USA arrivano ogni tanto diffusione di notizie riservate che permettono
di sapere queste cose).
Forse si vuole anche diffondere il panico tra gli utilizzatori di Linux,
perché cosi aumentano le vendite di Computer nuovi.
no, anche i PC nuovi attuali hanno questi bug hardware e questi bug non
sono risolvibili via software (almeno così dicono gli esperti).
Ciao
Davide
[1] ho fatto una ricerca rapida e trovato questo articolo:
http://www.zdnet.com/article/borland-interbase-backdoor-detected/
--
Dizionari: http://linguistico.sourceforge.net/wiki
I lati oscuri del secure boot:
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web
Petizione contro il secure boot:
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook
Reply to: