Architetture x86: una falla vecchia di 20 anni espone al rischio rootkit

[Marco71]

...l'aggiornamento del microcodice (tecnicamente "patch") non è in auge "da sempre" come scritto poco sopra.
Parlo ovviamente di sistemi a cpu in forma di circuito integrato e nella fattispecie dei prodotti Intel.
Il primo processore ad avere l'opportunità di avere correzioni al microcodice fu il Pentium Pro alias P6 dal nome della omonima microarchitettura.
Ciò a cui ci si riferisce sopra è ad esempio la famosa voce dei bios Award like "Bios update".

https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAAahUKEwiu6pKYo5_HAhUF0hoKHUdOCFs&url=https%3A%2F%2Fwww.dcddcc.com%2Fpubs%2Fpaper_microcode.pdf&ei=3v7IVa6DN4Wka8ecodgF&usg=AFQjCNHqb2ZQjvmD_T0qvZ0Ys30P7Rcr7w&sig2=F5LbcoEGDApyIS7dQyyxDw&bvm=bv.99804247,d.bGQ

Marco71.

[TheQ.]

Internet of (bug) things

Ovvero, gente che vuole implementare falle (bug) in ogni cosa.

[Marco71]

https://www.dcddcc.com/pubs/paper_microcode.pdf

Marco71.

[bobafetthotmail]

Originariamente inviato da lucusta

ni, Pier; se cambi il microcode di una CPU aggiornare anche il bios della scheda madre, che deve riconoscere la CPU

No, del bios freganiente. Deve avere l'ID del processore nel suo registro e sapere cosa fare per farlo andare (o dove stanno sensori e roba varia), il microcode è un'altra cosa.
Comunque il microcode caricato dal BIOS è quasi sempre scarso ma sufficiente a far girare tutto finchè non carica un OS.

non è in auge "da sempre" come scritto poco sopra.

20 anni circa? Non sarà "sempre" in senso assoluto ma è certamente un tot di tempo specialmente in campo IT, quindi me la passerai sta leggera esagerazione.

Internet of (bug) things

Già.... skynet è un gattino al confornto del casino che l'IoBoT (Internet of Bugs of Things) porterebbe...

[Totix92]

Se è come penso prima o poi intel aggiornerà i microcode, poi li passerà a microsoft che con un'aggiornamento li installa nei sistemi, se non sbaglio i microcode delle cpu intel su windows stanno nel file intelppm.sys

[TheQ.]

Originariamente inviato da bobafetthotmail

Già.... skynet è un gattino al confornto del casino che l'IoBoT (Internet of Bugs of Things) porterebbe...

Casualmente in io(ro)Bot il computer cattivo stile Skynet aggirava i vincoli delle tre regole sfruttando internet come una falla al blocco hardware.

Essendo una falla 20-ennale chissà se butteranno fuori aggiornamenti per Windows 98 e Windows XP.
Il problema colpisce anche linux?

[Benjamin Reilly]

un falla... alcune CPU, una caratteristica.


Cioè!? Non si capisce niente.

[Benjamin Reilly]

Originariamente inviato da bobafetthotmail

Come detto prima, il microcode integrato nel processore è una ROM.

Da sempre i sistemi operativi caricano dei microcode più aggiornati con un driver all'avvio, ma al riavvio devono caricarli di nuovo, il microcode della CPU è una ROM non puoi cambiarla, solo sostituirlo con uno più aggiornato mentre avvii la macchina.

Quindi sì. Se è fatto prima del 2010, cambiare processore (e probabilmente PC) ragazzi.

paghi tu o chi è responsabile della falla?

tra 5 anni scopriranno la falla negli attuali processori, sicchè le falle se esistono, le fanno apposta e quando le rivelano costringono agli acquisti con la paura: così attraverso il terrore la gente compra. Se non hanno altri metodi per vendere i loro prodotti, chiudessero.

Cmq i sistemi linux possono installare loro microcode. Se ciò previene da rischi si passi ai sistemi linux.

Spero che qualcuno faccia cause milionarie.

[giovanni69]

Tale bug nel microcode dovrebbe aver effetto anche nelle CPU delle macchine virtuali (VM) oppure no?

[Benjamin Reilly]

2009 stessa notizia

http://www.cnet.com/news/intel-chip-...t-what-of-it/#!

[BulletHe@d]

Nel caso delle Virtual Machine dovrebbe essere tutto risolvibile con una patch del software stesso paradossalmente in questo caso sono più sicure loro che quelle vere di macchine XD

IN generale cmq se il bug riguarda i microcode della CPU credo che nessun S.O. sia al sicuro visto che tale microcode se non sbaglio è tipo una rom quindi win o Linux o qualunque altro S.O. non installa il proprio ma semplicemente sovrascrive per quella sessione il loro codice che viene dimenticato al primo spengimento/riavvio dello stesso

[bobafetthotmail]

Originariamente inviato da TheQ.

Casualmente in io(ro)Bot il computer cattivo stile Skynet aggirava i vincoli delle tre regole sfruttando internet come una falla al blocco hardware.

Stesso problema delle auto crysler. Qualche deficiente ha connesso l'AI ad internet senza un filtro hardware.

Per non parlare del deficiente che ha scritto le parti che dovevano fare ragionamenti logici per mettere giù un piano decente....

Ok per il prendere il controllo del mondo per proteggere gli uomini da sè stessi (ce ne sarebbe bisogno e sarebbe anche in accordo con le 3 leggi), ma ci sono modi molto più efficaci che comportarsi come un bambino arrabbiato.

Tipo ad esempio giocare in borsa e comprare eventualmente tutto e controllare tutti dall'ombra come "potere occulto".

Gli dò il beneficio della giovnetù comunque. Magari erano effettivamente molto immature e quindi la colpa ricade sui genitori sviluppatori che non hanno saputo gestirle.

Essendo una falla 20-ennale chissà se butteranno fuori aggiornamenti per Windows 98 e Windows XP. Il problema colpisce anche linux?

Quale parte di "è il firmware delle CPU" non hai compreso?
Non possono fare patch, il BIOS e l'OS sono irrilevanti.

paghi tu o chi è responsabile della falla?

Paga il consumatore, ma che domande fai...

Cmq i sistemi linux possono installare loro microcode. Se ciò previene da rischi si passi ai sistemi linux.

I microcode sono dei blob proprietari distribuiti con licenza permissiva da Intel e AMD.
Perchè è il firmware che fa funzionare il processore, Linux, Windows, OSX, Solaris (Unix) eccetera caricano la stessa roba.

Come detto comunque nell'articolo, per poter sfruttare la falla il malware deve avere accesso al livello kernel o sistema operativo (livelli di privilegi superiori all'amministratore/root che è solo un superutente).

Perchè per caricare un microcode nel processore devi essere/controllare un driver che è in genere integrato nel kernel.

Questa falla è una falla che permette ad un malware già entrato di avere poteri elevatissimi, non una falla che permette ad un malware di entrare. (ci vogliono entrambe perchè un malware funzioni, quindi non vanno sottovalutate)

Quindi Linux/Unix sono più sicuri da questo punto di vista (visto che è più difficile penetrare in una macchina non-windows e escalare i privilegi fino ad avere privilegi da kernel).
Ma non sono immuni.
Perchè è l'hardware che è vulnerabile. Puoi solo cambiare il pezzo per avere la sicurezza.

tra 5 anni scopriranno la falla negli attuali processori, sicchè le falle se esistono, le fanno apposta e quando le rivelano costringono agli acquisti con la paura:

Ne dubito. Sai quanta gente continua ad usare XP senza farsi domande? Ecco, figurati quanti resteranno con un processore che ha questo problema.

Comunque, detto tra noi, il problema dei microcode si risolve facilmente alla radice. Tieni microcode e cazzi vari una minimemoria ROM da qualche parte nella scheda, con due connessioni, una diretta al processore e puramente hardware che si gestisce lui e lui solo, una che permette gli aggiornamenti di fianco ad un interruttore VERO che stacca il contatto fisicamente.

Quando devi aggiornare i microcode nella minirom devi spostare l'interruttore, mentre il processore quando si avvia li pesca da solo da questa mini ROM senza che BIOS o OS ci possano fare nulla.

Vale la stessa storia per i BIOS cosiddetti "sicuri" o "protetti dalla scrittura". Non mi frega un cazzo della chiave crittografica che li cripta e dei bootloader bloccati (che caricano solo i BIOS firmati correttamente), dammi un fottuto interruttore che stacca il contatto e non permette ALCUNA scrittura nella EEPROM a livello fisico se non QUANDO LO DICO IO (prechè qui comando io, perchè qui è casa mia... come diceva la canzone ).

BUM, problema risolto, per sempre.

Spero che qualcuno faccia cause milionarie.

Improbabile, costa meno cambiare il pezzo.
Comunque concordo, è scandaloso.

Tale bug nel microcode dovrebbe aver effetto anche nelle CPU delle macchine virtuali (VM) oppure no?

No, perchè il microcode lo carica il sistema operativo host, o l'hypervisor (Xen, KVM, EsXI di VMWare, eccetera), la VM non ha una cippa di controllo sull'hardware se non glie lo passi tu con il vt-d o IOMMU (permettono di dare controllo diretto di una scheda ad una VM), è un "guest", un ospite.

Per sfruttare la falla dovresti riuscire a craccare il sistema operativo host (o l'hypervisor).
Con un hypervisor è abbastanza arduo visto che di fatto è solo un kernel linux segato all'osso + 4 minuscole utility di configurazione che non dialogano con l'esterno tranne via ssh o equivalenti (terminale remoto).

Però montare un hypervisor e fare un passthrough della GPU e/o altre schede tipo audio o storage (per giocarci o per lavorarci) non è esattamente alla portata di tutti.

[sbaffo]

Originariamente inviato da Redazione di Hardware Upgrade

Link alla notizia: http://www.hwupgrade.it/news/sicurez...kit_58347.html

Una caratteristica inserita nel 1997 nelle architetture x86 ha aperto una vulnerabilità che può consentire, in talune circostanze, di installare rootkit a basso livello per compromettere un sistema in maniera persistente ed invisibile

Una volta installato il rootkit potrebbe essere usato per attacchi anche piuttosto gravi, come ad esempio la cancellazione dell'UEFI o la reinstallazione di malware anche a seguito di una installazione del sistema operativo

Ciò che viene detto nell'articolo non quadra con quanto dite sotto. Se reinstallo il SO farò bene un riavvio, spero.

Originariamente inviato da bobafetthotmail

Come detto prima, il microcode integrato nel processore è una ROM.

Da sempre i sistemi operativi caricano dei microcode più aggiornati con un driver all'avvio, ma al riavvio devono caricarli di nuovo, il microcode della CPU è una ROM non puoi cambiarla, solo sostituirlo con uno più aggiornato mentre avvii la macchina.

Quindi sì. Se è fatto prima del 2010, cambiare processore (e probabilmente PC) ragazzi.

Originariamente inviato da bobafetthotmail

Conosci i microcode? Le CPU aggiornano il firware (che di per sè sarebbe read-only, e al riavvio l'aggiornamento non resta) ogni volta che avvi un sistema operativo decente che glie li aggiorna con un driver.

Originariamente inviato da BulletHe@d

IN generale cmq se il bug riguarda i microcode della CPU credo che nessun S.O. sia al sicuro visto che tale microcode se non sbaglio è tipo una rom quindi win o Linux o qualunque altro S.O. non installa il proprio ma semplicemente sovrascrive per quella sessione il loro codice che viene dimenticato al primo spengimento/riavvio dello stesso

Quindi se l'articolo ha ragione il bug permette di scivere nel processore (smm) qualcosa di permanente. Imho.

[Benjamin Reilly]

quind i firmware delle cpu possono essere aggiornati? nel caso perchè intel non rilascia tali aggiornamenti? e cosa indicherebbe la presenza del malware!?

[BulletHe@d]

@sbaffo
non in modo permanente ma una volta avuto accesso al sistema nessuno gli vieta di inserire una routine poggiata a quella dell'S.O. che ne riaggiorna l'inserimento ad ogni riavvio, in fondo ti bassa accedere una sola volta per poi fare danno

@Benjamin Reilly
non è così semplice essendo una parte di microcode non sovrascrivibile (se non solo a titolo temporale) non esiste una soluzione definitiva, al max tramite S.O. possono fare in modo che ad ogni riavvio venga inserito un microcode aggiornato a sovrascrivere quello buggato per la sessione ma è una soluzione temporanea e non definitiva senza contare che ciò prevede alla base un S.O. che continua ad essere aggiornato quindi quelli in cui il supporto è cessato rimangono vulnerabili

[bobafetthotmail]

Originariamente inviato da sbaffo

Ciò che viene detto nell'articolo non quadra con quanto dite sotto. Se reinstallo il SO farò bene un riavvio, spero.

Parla anche di cancellazione dell'UEFI. Attenzione che la scheda madre ha una EEPROM con il suo firmware, (il BIOS/UEFI), dove potrebbe scrivere sfruttando l'accesso che ha acquisito con questa vulnerabilità, e dopo l'unico modo per levarlo da lì è riflashare il BIOS manualmente (da DOS), sperando che la procedura di flash cancelli il malware (non tutta la EEPROM viene cancellata sempre, dipende), o cambiando fisicamente il chip di memoria con uno nuovo.

Un pò come i virus che si infilavano nel MBR (settore di avvio) dei dischi fissi, solo che lo fanno con la scheda madre.

Questo tipo di exploit vengono usati per malware di alto e altissimo livello come questi qui (dai bersagli del gruppo di hacker si direbbe che siano pagati dagli USA, così per dire eh)
https://securelist.com/blog/research...alware-galaxy/ (sito di kaspersky, non è un blog delirante)
Che come si nota a pag 10 e 11 del documento pdf, diventano un hypervisor, al sicuro da antivirus e qualsiasi cosa mentre patchano driver, software e controller del disco fisso per origliare con scioltezza. Su windows.
Quello in oggetto usa il MBR, ma è anche un malware di 2-3 anni fa.

quind i firmware delle cpu possono essere aggiornati? nel caso perchè intel non rilascia tali aggiornamenti?

I firmware delle CPU sono scritti in una ROM nel processore, ma possono essere aggiornati temporaneamente (fino al riavvio) da un driver particolare integrato nei vari OS e nei BIOS (che supportano tale processore).

La vulnerabilità stà proprio in questa aggiornabilità del firmware, se non fosse aggiornabile questi giochini non si potrebbero fare senza aprire fisicamente la macchina.

e cosa indicherebbe la presenza del malware!?

Boh, dipende da quello che fa, come tutti i malware.

Questa è solo una porta apribile.

In genere se il PC è windows si fa girare un Rescue CD, un antivirus montato su un OS linux che fa scansioni del disco mentre il malware è inattivo. Da linux non saprei, ci sono strumenti diagnostici ma non ho mai usato roba del genere.

Ma se il maledetto si è infilato nel BIOS/UEFI sfruttando questa roba qui... eh...

[Benjamin Reilly]

in sostanza nemmeno sarebbe facile capire se si sia infetti o meno eccettuato il caso di cancellazione del bios... in quanto latente.

[BulletHe@d]

Piccola Riflessione:
l'articolo cita che le CPU colpevoli sono quelle prodotte fra il 97 ed il 2010, ora se non erro quelli sono gli anni che vanno dal Pentium Pro (se non erro la prima CPU su cui si poteva sovrascrivere il microcode temporaneamente) ai Core di prima generazione (ad essere precisi nel suo refresh ovvero Westmere) quindi da SandyBridge in avanti dovremmo essere tutti al sicuro stando alle info fin'ora emerse

[bobafetthotmail]

Originariamente inviato da BulletHe@d

quindi da SandyBridge in avanti dovremmo essere tutti al sicuro stando alle info fin'ora emerse

Sì esatto. Dicono anche che gli AMD non li hanno testati e che potrebbero essere vulnerabili ma non si sa.

Comunque, su tutti i processori attuali il microcode viene aggiornato nello stesso modo (concettualmente parlando).

Nella pratica ad Intel devono aver cambiato qualcosa di come funziona il sistema e quella vulnerabilità non esiste più su CPU prodotte dal 2010 in poi.

Ma non c'è nulla che ti rassicura sul fatto che i processori dal 2010 in poi siano sicuri, solo che quella vulnerabilità lì non c'è più.

Quindi si sta all'occhio che magari esce un altro documento che bum, tutti i processori Intel sono vulnerabili.

[TheQ.]

C'è un po' di confusione fra chi parla di aggiornamenti di file e chi parla di aggiornamenti di BIOS e chi parla di bug del sistema di aggiornamento del CPU che modifica in modo irreparabile il codice di funzionamento della CPU.
E si che se la notizia è nota dal 2009 come prima indicato c'era il tempo per capire questa questione
^_^'''