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

Rispondere a