Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/architetture-x86-una-falla-vecchia-di-20-anni-espone-al-rischio-rootkit_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

Click sul link per visualizzare la notizia.

"Per poter sfruttare la falla e installare il rootkit l'attaccante dovrebbe già avere privilegi di kernel"


vabbè, un non-problema

"Per poter sfruttare la falla e installare il rootkit l'attaccante dovrebbe già avere privilegi di kernel"


vabbè, un non-problema

per la precisione l'articolo originale dice "need to have kernel or system privileges on a computer"

non è raro trovare in circolazione malware che girano con quel livello di privilegio

il problema imho è che si sta mettendo troppa roba "lato hardware", creando una superficie d'attacco notevole, in zone la cui esistenza è sconosciuta all'utente medio e dove gli antivirus non possono mettere mano

e onestamente non comprendo il perchè si stia procedendo in questa direzione

"Per poter sfruttare la falla e installare il rootkit l'attaccante dovrebbe già avere privilegi di kernel"


vabbè, un non-problema
mica tanto, vuol dire che una vola infettato devi buttare la cpu perchè si è installato nel firmware. Sempre che te ne accorga, perchè a quel punto non è più rilevabile.
Mi puzza tanto di nsa...

per la precisione l'articolo originale dice "need to have kernel or system privileges on a computer"

non è raro trovare in circolazione malware che girano con quel livello di privilegio

il problema imho è che si sta mettendo troppa roba "lato hardware", creando una superficie d'attacco notevole, in zone la cui esistenza è sconosciuta all'utente medio e dove gli antivirus non possono mettere mano

e onestamente non comprendo il perchè si stia procedendo in questa direzione

mica tanto, vuol dire che una vola infettato devi buttare la cpu perchè si è installato nel firmware. Sempre che te ne accorga, perchè a quel punto non è più rilevabile.
Mi puzza tanto di nsa...
Appunto, secondo me in questo modo rendono la vita più facile a chi vuole "controllare"

Il problema è che quella versione sia writable. Capisco la possibilità di aggiornare il firwmare di una CPU (ma quando mai, poi?), ma IMHO sarebbe stato meglio fosse stata read-only.
Poi vabbé, non ho approfondito, quindi potrei aver detto una cazzata :D

By(t)e

Come diceva coso, come si chiama... sbaffo, mi sa tanto che sia una falla governativa. Magari non e' una falla di design, puo' essere davvero non voluta, ma credo che alla NSA e non solo lo sapessere quasi fin dalle origini.
E va a sapere cosa abbiamo al giorno d'oggi nei nostri dispositivi.

il no sense resta sull'impossibilità di avere una lista di cpu fallate o meno ed i tempi in cui Intel e AMD vogliono metterci la patch.

da ricordare però anche che
"Even if BIOS/UEFI updates are made available by computer manufacturers, their rate of adoption is likely to be very low, especially among consumers."

qui http://www.engadget.com/2015/08/08/intel-memory-sinkhole-flaw/ si parla delle CPU prodotte tra il 1997 e il 2010.

qui http://www.engadget.com/2015/08/08/intel-memory-sinkhole-flaw/ si parla delle CPU prodotte tra il 1997 e il 2010.

appunto

diranno che "non è facile trovare ed usare vulnerabilità in quel codice", ma poi quando se ne trova una è una strage

e ovviamente quel tipo di memorie non può essere a sola lettura, proprio perchè può essere necessario dover aggiornare il codice

come accade col software "normale" insomma, con la differenza che questo software qui è opaco, sconosciuto ai più, ficcato in posti difficilmente accessibili, ecc...

ma loro arriveranno e ci diranno "ecco perchè vogliamo criptare tutto e ficcarvi il tpm ovunque", solo che la storia dimostra che le chiavi usate per questi scopi hanno la tendenza a farsi rubare

mah, sarò complottista, però a me sembra che gli unici a guadagnarci da tutta questa charade siano gli spioni

Toh, mettere dei firmware merdacchiosi nell'hardware causa falle di sicurezza... :fagiano:

Il problema è che quella versione sia writable. Capisco la possibilità di aggiornare il firwmare di una CPU (ma quando mai, poi?), ma IMHO sarebbe stato meglio fosse stata read-only.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.

mah, sarò complottista, però a me sembra che gli unici a guadagnarci da tutta questa charade siano gli spioniAnche chi vende i processori... :read:

Le falle di sicurezza di un sistema servono ad invogliare a comprare quello successivo, che non ha quelle falle. (ma amgari ne ha altre)

...la possibilità di "variazione" delle routine del microcodice per le cpu Intel x86 fu introdotta all'indomani del famosissimo bug nell'algoritmo SRT delle fpu dei processori Pentium...
Con il possente Pentium PRO...la cui fpu fu verificata in modo "molto esaustivo".
Se non mi ricordo male comunque il S.M.M fu introdotto con l'80386SL che era destinato ai computer portatili.
https://en.wikipedia.org/wiki/System_Management_Mode

https://en.wikipedia.org/wiki/System_Management_Mode#/media/File:NSA_SOUFFLETROUGH.jpg

E' ovvio che "gente" come NSA ed anche ciò di cui non si conosce nemmeno l'esistenza sappiano con eoni di anticipo di questi problemi.
Molti dei quali potrebbero essere anche desunti dagli errata pubblicati dai produttori di cpu.

Marco71.

...nemmeno "cosa nuova"...
Notare la data di pubblicazione...
http://www.ssi.gouv.fr/archive/fr/sciences/fichiers/lti/cansecwest2006-duflot.pdf

Marco71.

20 anni fa non c'era l'UEFI, quindi è forse una falla presente in codice di 20 anni fa che agisce sull'UEFI che ha sostituito il BIOS solo negli ultimi anni.
Sbaglio?

Non ho capito se questa falla è stata scoperta dopo 20 anni, oppure ne erano a conoscenza e nessuno ha detto niente.

In entrambi i casi la cosa è preoccupante..

Non ho capito se questa falla è stata scoperta dopo 20 anni, oppure ne erano a conoscenza e nessuno ha detto niente.

In entrambi i casi la cosa è preoccupante..

Non è una cosa nuova, il SMM è di per se stesso un rootkit "a fin di bene"
pensato per ridurre i costi dell'hardware (delegando a livello software roba che in precedenza veniva per forza gestita in hardware), per chi fa roba ad alte prestazioni è anche una gran rottura di co****ni perche riesce anche ad interrompere software in teoria hard realtime e sputtanare le latenze (specialmente se il software SMM è scritto con il cu:ciapet:o ).

In pratica il tipo ha trovato un modo più semplice per accedere al firmware e sovrascrivere il software SMM oppure ridirezionare il vettore dell'SMI (System Management Interrupt).

20 anni fa non c'era l'UEFI, quindi è forse una falla presente in codice di 20 anni fa che agisce sull'UEFI che ha sostituito il BIOS solo negli ultimi anni.
Sbaglio?Sbagli. :D

Questa falla è nel firmware del processore, il cosiddetto "microcode".

Dà accesso completo al sistema con livello di priorità più elevato, più di root e kernel, visto che è il firmware del processore, della macchina che fa girare tutta la baracca.

Poi dicono che puoi usarlo per cancellare l firmware UEFI e fare altra roba varia, ma BIOS o UEFI cambia niente, non sono quelli che hanno la falla.

Ed è anche la ragione per cui i Secure Boot è inutile contro questo attacco (come se in generale fosse utile a fare altro che non sia rompere le balle a chi non usa Windows 8 o successivi...).

Non è una cosa nuova, il SMM è di per se stesso un rootkit "a fin di bene"per "bene" si intende comunque dal punto di vista dei costruttori... :rolleyes:

Non ho capito se questa falla è stata scoperta dopo 20 anni, oppure ne erano a conoscenza e nessuno ha detto niente.
Dall'articolo: Secondo quanto riferisce il ricercatore, Intel sarebbe a conoscenza del problema e nelle più recenti CPU avrebbe trovato il modo di porvi rimedio.

Ora, se le CPU dal 2010 in poi non hanno questa vulnerabilità i casi sono due:
-Intel ha cambiato qualcosa e per una botta di culo ha chiuso la falla senza neanche sapere che c'era
-Intel sa della falla da ALMENO 4-5 anni.

Non è una cosa nuova, il SMM è di per se stesso un rootkit "a fin di bene"
pensato per ridurre i costi dell'hardware (delegando a livello software roba che in precedenza veniva per forza gestita in hardware), per chi fa roba ad alte prestazioni è anche una gran rottura di co****ni perche riesce anche ad interrompere software in teoria hard realtime e sputtanare le latenze (specialmente se il software SMM è scritto con il cu:ciapet:o ).

In pratica il tipo ha trovato un modo più semplice per accedere al firmware e sovrascrivere il software SMM oppure ridirezionare il vettore dell'SMI (System Management Interrupt).

Sbagli. :D

Questa falla è nel firmware del processore, il cosiddetto "microcode".

Dà accesso completo al sistema con livello di priorità più elevato, più di root e kernel, visto che è il firmware del processore, della macchina che fa girare tutta la baracca.

Poi dicono che puoi usarlo per cancellare l firmware UEFI e fare altra roba varia, ma BIOS o UEFI cambia niente, non sono quelli che hanno la falla.

Ed è anche la ragione per cui i Secure Boot è inutile contro questo attacco (come se in generale fosse utile a fare altro che non sia rompere le balle a chi non usa Windows 8 o successivi...).

per "bene" si intende comunque dal punto di vista dei costruttori... :rolleyes:


Dall'articolo: Secondo quanto riferisce il ricercatore, Intel sarebbe a conoscenza del problema e nelle più recenti CPU avrebbe trovato il modo di porvi rimedio.

Ora, se le CPU dal 2010 in poi non hanno questa vulnerabilità i casi sono due:
-Intel ha cambiato qualcosa e per una botta di culo ha chiuso la falla senza neanche sapere che c'era
-Intel sa della falla da ALMENO 4-5 anni.

questo punto mi chiedo se è possibile fixare la falla con un aggiornamento firmware rilasciato da Intel.
Ma mi sembra di capire che non sia possibile a meno di non sostituire il processore con uno recente...

questo punto mi chiedo se è possibile fixare la falla con un aggiornamento firmware rilasciato da Intel.
Ma mi sembra di capire che non sia possibile a meno di non sostituire il processore con uno recente...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.

ni, Pier; se cambi il microcode di una CPU aggiornare anche il bios della scheda madre, che deve riconoscere la CPU; se la scheda madre adatta allle più recenti cpu fallate ha già 10 anni 6 anni, credo che solo sistemi embedded, custom, di nicchia o industriali ne beneficieranno, in quanto non c'e' produttore reital che ti aggiornerebbe un bios di 6 anni fa' od oltre.

bios di schede usate nei sistemi embedded tipo gli ATM?
ti fanno aggiornare il sistema, che tanto non e' l'unica falla che hanno!

...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.

Internet of (bug) things :D

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

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

Marco71.

ni, Pier; se cambi il microcode di una CPU aggiornare anche il bios della scheda madre, che deve riconoscere la CPUNo, 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) thingsGià.... skynet è un gattino al confornto del casino che l'IoBoT (Internet of Bugs of Things) porterebbe...

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

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?

un falla... alcune CPU, una caratteristica.


Cioè!? Non si capisce niente.

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.

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

2009 stessa notizia

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

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

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... :rolleyes:

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 :D ).

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.

Link alla notizia: http://www.hwupgrade.it/news/sicurezza-software/architetture-x86-una-falla-vecchia-di-20-anni-espone-al-rischio-rootkit_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.
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.


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.



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.

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

@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

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/68750/equation-the-death-star-of-malware-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...

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

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

quindi da SandyBridge in avanti dovremmo essere tutti al sicuro stando alle info fin'ora emerseSì 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.

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
^_^'''

C'è un po' di confusione
Dall'articolo su HWU
Sfruttando questa vulnerabilità è possibile installare un rootkit nel System Management Mode del processore, una porzione protetta di codice che sta alla base tutte le caratteristiche di sicurezza firmware nei moderni computer.

Cos'è il SMM? http://www.computerhope.com/jargon/s/smm.htm
"a way for the CPU to execute code from a separate area of memory known as SMRAM. SMRAM is only accessible by the processor and not the operating system or other programs."

Cos'è la SMRAM? http://www.computerhope.com/jargon/s/smram.htm
"SMRAM is a portion of the systems memory used by the processor to store code used with SMM."

Quindi è ram tenuta separata dal resto della ram a livello hardware. Al riavvio svanisce.

Ma il problema è quello che fai finchè hai accesso a questa SMM, Questo è un privilege escalation supremo, al livello dell'hardware, rende quello che fai praticamente invisibile (se non c'è un ingegnere Intel che sta facendo un debug serio del processore) e impossibile da fermare (visto che manco il kernel sa che cosa diavolo stai facendo perchè quella ram è privata e non la può usare, quindi l'OS e tutti i programmi non ne sanno nulla).

Una volta che hai accesso a questo puoi infilare dei backup del tuo malware dove ti pare per mantenere la porta aperta al riavvio. Nel BIOS? Nei controller dei dischi? Dentro ad una scheda? Nel MBR? In tutti questi citati insieme? Si può fare.

Possono dire che patchano la cosa con una nuova versione di microcode, ma ad un malware basta settare il sistema operativo per caricare un microcode più vecchio quando si avvia e poi può fare di nuovo la qualunque.

E si che se la notizia è nota dal 2009 Che gestita in questo modo fosse una idea stupida si sapeva comunque da tempo.

Ho capito molto poco, ma penso di aver capito la sostanza.
Se qualcuno riesce a sfruttare questo bug ottiene privilegi che neanche l'amministratore ha, quindi può agire completamente indisturbato visto che nessun antivirus è in grado di riconoscerlo, può agire a basso livello e in completo anonimato.

Scusate, ma questa non sarebbe una falla da sistema operativo che normalmente si chiude con un bugfix negli aggiornamenti, questo è proprio un errore madornale progettuale del processore, a cui non c'è rimedio se non cambiando PC, e sticazzi...

falla di cui dal 2009 si è a conoscenza e che dalle cpu del 2010 non ha più effetto, sostanzialmente com'è uscito il caso hanno provveduto a fare le correzioni sulla prima produzione utile ovvero al cambio di architettura, e fin qui ci può stare, il problema ora è c'è modo di proteggere anche le produzioni incriminate (97-2010) ? bella domanda da i commenti letti finora mi verrebbe da dire "ni", o meglio, se un sistema che ha una di quelle cpu è ancora pulito allora in teoria con opportune patch si può ovviare temporalmente al problema (il discorso dei microcode aggiornate temporaneamente dall'so) ma in caso di sistema infettato l'unica certezza di eliminare il problema è solo quello di cambiare hw (visto che una volta infettato il sistema ha troppe vie dove il virus può nascondersi e fare danno.

che la falla sia presente s'è capito, ciò che non si capisce è il metodo per rilevare l'eventuale presenza del rootkit.

Ho capito molto poco, ma penso di aver capito la sostanza.
Se qualcuno riesce a sfruttare questo bug ottiene privilegi che neanche l'amministratore ha, quindi può agire completamente indisturbato visto che nessun antivirus è in grado di riconoscerlo, può agire a basso livello e in completo anonimato.Fin qui arriva comunque anche una falla grave dell'OS.

Questa va oltre, permette di fare cose che neanche con una falla grave dell'OS puoi fare, cioè infettare l'hardware in modo più o meno permanente, oltre che avere mano molto più libera su quello che fanno comunque già (ma sbattendosi parecchio di più, quindi è comunque utile).

ci sono vari livelli di privilegi (cioè di accesso a componenti e operazioni sensibili che vengono accordate)
in ordine crescente:
-utente
-admin/superutente/root
-sistema operativo
-kernel
-smm del processore

I sistemi informatici sono stati compartimentalizzati da tempo per rendere più difficile il lavoro al malware (ma anche gestire driver merdacchiosi e instabili, la feature di Vista e successivi del "il driver video è crashato e lo abbiamo riavviato" è possibile perchè il driver non gira come OS o kernel ma come utente, una delle ragioni per cui Win98 e 95 erano instabili era perchè i driver giravano con priorità troppo alta e quando crashavano si tiravano dietro tutto). Se bastava che il malware avesse accesso root per fare il diavolo a quattro stavamo freschi.

falla di cui dal 2009 si è a conoscenza e che dalle cpu del 2010 non ha più effetto,Sì, ma cosa ti assicura che non ce ne siano altre che verranno scoperte "ufficialmente" tra anni?
Un sistema sicuro è sicuro perchè è stato progettato per essere sicuro e segue delle linee guida, non perchè vanno avanti a casaccio e levano i bug man mano che si va avanti.

Questo è hardware dannazione. Non puoi aggiornarlo ma solo sostituirlo.

Per fare un esempio pratico, quelle auto della crysler che hanno il tablet di bordo connesso ai circuiti di comunicazione interna di tutti i sistemi elettronici della macchina non sono diventati "sicuri" ora che patchano la vulnerabilità scoperta.

Alla prossima vulnerabilità del sistema si ritorna daccapo.

I firmware del processore come il BIOS come tutta l'altra roba non deve essere scrivibile se qualcuno non sblocca un tastino, il resto che si inventano è craccabile.

il problema ora è c'è modo di proteggere anche le produzioni incriminate (97-2010) ?Molto probabilmente no. Perchè un malware con privilegi da OS o da kernel (necessario per fare questo giochino a prescindere) può tranquillamente cambiare microcode con uno fallato, poi agire.

che la falla sia presente s'è capito, ciò che non si capisce è il metodo per rilevare l'eventuale presenza del rootkit.Non puoi. Se non fa cazzate il rootkit come impallare la connessione internet o fare qualcosa di eclatante, non c'è modo di capire che c'è, perchè sfrutta il sistema che garantiva la sicurezza dell'hardware per pararsi il didietro.

Quando avvii la macchina e il maledetto sta nel BIOS o da qualche parte, si avvia anche quello e si infila nel SMM, dove è al riparo da qualsiasi cosa a parte un debug da parte di un ingegnere Intel che ha accesso ad informazioni e strumenti che hanno solo loro (che usano per sviluppare la loro roba e quindi non ti danno), e da lì può inchiodare o ridirigere o fare il furbetto per evitare che un antivirus trovi le sue copie nel BIOS o nel disco o ovunque.

Un rootkit da sistema operativo lo pialli con un Rescue Disk di un antivirus (che è un OS linux e agisce su un sistema operativo non attivo quindi su dati fissi che non possono reagire), questo dovresti avviare la scheda madre con un nuovo BIOS e sperare che non si sia infilato da qualche altra parte nella scheda.

e fu così che anche l'hardware si ammalò inesorabilmente come un essere umano.
impressionante. a quando i roghi per bruciare tutto?

http://www.msuiche.net/2008/08/06/smm-rootkit-limitations-and-how-to-defeat-it/

sto studiando.

in parole povere se metti il pc infetto in ibernazione e riavvii ti ritrovi la memoria pulita.
è del 2008, sarà ancora attuale?

in parole povere se metti il pc infetto in ibernazione e riavvii ti ritrovi la memoria pulita.
è del 2008, sarà ancora attuale?

sostanzialmente la memoria è ripulita, il lato processore (SMM) non so parrebbe di sì leggendo l'obiettivo, ma questo tipo di infezione non è molto comune, è cmq complessa, coinvolge hardware specifico e bios specifici non protetti, impegna apic lapic i/o apic, tabelle di indirizzi... sostanzialmente è una sorta di meccanica morse che si annida nell'SMM e poi è trasferito sulle memorie ram nell'area SMMRAM.... secondo me il primo che ha progettato sta cosa poi si è ricoverato in una clinica psichiatrica.

Da quanto sto comprendendo è un problema noto anche prima del 2009. La variante VMMR ad esempio opera solo se il processore supporta la virtualizzazione.

Se un rootkit lo freghi con questi trucchetti basta anche un riavvio brutale o un semplice spegnimento... Che rootkit è?

When, the computer will boot again (REMEMBER: Hardware reset is the only way to clear the SMRAM, include SMRAMC control register which contains the D_LCK bit), BIOS will rewrite the SMRAM during its initialization.

Se il malware si è inserito nel BIOS col cavolo che sto giochino lo frega perchè al riavvio ricarica tutto tr acui il malware nella SMRAM, di cosa stavo parlando opra?

while the Windows OS Boot loader will be executed it will read the saved hibernation file wich DO NOT contains the infected SMRAM and the system will resume normaly. Your system is now virgin!

Virgin my ass. Dafuq?

è comunque palesemente compromesso. Il rootkit gli ha patchato driver, librerie di sistema e varia altra roba solo per arrivarci alla SMRAM (gli serve il livello di privilegio OS o kernel, i più elevati che un OS può fornire, non ci arriva a caso).

Se si parla di dopo formattone serio per pulire il disco è aplese che il rootkit deve pur stare da qualche altra parte, visto che la SMRAM è comunque RAM e sparisce quando il PC si spegne, cosa li acquisisce da fare i superpoteri se non li usa?

è del 2008, sarà ancora attuale?
BIOS Vendors enables this bit for some years (maybe like 2/3 years), few times after Loic Duflot first lecture. It means that “new computers” are not vulnerable to this.

Cioè la SMRAM è sempre inaccessibile ora, il valore è sempre 1.

Quindi sto giochino non va più ora.

se si è inserito nel bios allora basta flasharlo di nuovo, inoltre se il bios è loccato ossia protetto non accede. Occorre solo sapere se il bios è dotato di tale protezione o meno.

L'espediente se ho capito funge grazie all'ibernazione, come agisca in ambito smm invece non l'ho capito o non è spiegato. Comprendo l'azzeramento smram, ma non il reset dell'SMM. Che memoria sarebbe!? volatile permanente che roba è!?

VMBRs operate in protected mode with paging enabled,
while SMBRs operate in a 16 bit environment similar to Real Mode without
paging. Finally, both VMBR’s and SMBR’s can be classified as
non-persistent rootkits. Non persistent rootkits exist only in
memory and lack the ability to persist across reboots on the
machine they are installed on. Although on the surface this
seems like a significant disadvantage, when one considers that
many server systems run for weeks or months at a time between
reboots, it becomes less of an issue. Due to the complex nature
of the SMBR, it is unlikely that such a rootkit will appear on the
more frequently rebooted systems (e.g. home user machines)
anytime soon.

Se ho compreso bene spento il computer la minaccia muore... quindi il problema è che se hai il file d'origine che lo carica lo ricarichi, ma a questo punto dovrebbe essere il file di origine rintracciabile come rootkit da un software anti-rootkit.

Solo per capire: paging sarebbe la funzione NX o XD!?

se si è inserito nel bios allora basta flasharlo di nuovo, Devi cambiare il chip del BIOS con uno nuovo, o flashare il chip esistente con un programmatore di EEPROM (un dispositivo per flashare un chip manualmente usando un altro PC, li usano in fabbrica e anche quelli che fanno assistenza).

Se avvii la scheda col BIOS compromesso e il rootkit che ha accesso al SMM si avvia con esso allora non ti lascia fare una sega, cioè ti fa credere che stai flashando ma in realtà non è vero.

O ti fa credere che stai scansionando il BIOS ma non te lo lascia fare davvero.

inoltre se il bios è loccato ossia protetto non accede. Loccato da cosa? Ci sono dei blocchi nei BIOS delle schede da server recenti e in alcuni portatili da azienda (non so quanto efficaci, specialmente in caso di violazione del SMM), ma nei BIOS consumer non c'è una cippa.

Occorre solo sapere se il bios è dotato di tale protezione o meno.Se è software bisogna anche sapere quanto vale da 1 a 10 questa "protezione".

Che memoria sarebbe!? volatile permanente che roba è!?Come detto sopra in risposta a TheQ, la SMM è una piccola parte della RAM del sistema, In genere qualche MB che appare come "hardware reserved" se guardi con le diagnostiche come Gestione Risorse.

Il processore la tiene separata dal resto della ram e inaccessibile da parte del kernel/OS perchè ci fa girare i fatti suoi.

Sappiamo tutti che in pochi MB ci sta un OS completo se non servono fronzoli, quindi puù farci la qualunque.

quindi il problema è che se hai il file d'origine che lo carica lo ricarichi, ma a questo punto dovrebbe essere il file di origine rintracciabile come rootkit da un software anti-rootkit.Sì, il punto è che se si infila nel BIOS mi spieghi come fai a scansionare il BIOS della scheda senza accenderla (e quindi senza caricare il coso nella SMM, e quindi rendere ogni scansione inefficace)?

Devi per forza smontare il chip del bios e usare un programmatore EEPROM.

Se entra dentro qualche altro componente della scheda madre (altri dispositivi hanno spazio per firmware e roba varia) che fai? Dissaldi pezzi?

Si entra nel magico mondo delle porte chiuse e del "è mio e non te lo dico", ossia dell'hardware e di come azzo funzionano i pezzi che compongono un PC, che aperti e opensource non sono praticamente mai.

Se ho compreso bene spento il computer la minaccia muore... La minaccia nella SMM muore, la minaccia nel BIOS o nella scheda resta.

Il punto è che se avviii la scheda madre/PC la minaccia ritorna nella SMM mentre si avvia tutto e sticazzi che riesci a sloggiare le minacce dal bios o dal resto della scheda.

Solo per capire: paging sarebbe la funzione NX o XD!?Paging è dividere la ram in blocchi così un processo può allocare pezzi di ram dove c'è spazio, e rende anche possibile la movimentazione di questi blocchi nel cosiddetto pagefile, il file di swap su disco di Windows.
Senza il paging tutta la ram usata da un processo deve essere contigua, se è frammentata le performance vanno a farsi benedire.

Ho letto più o meno tutti i post che avete scritto e da ciò mi è sorta una domanda: se la falla può essere sfruttata da un malware che ha privilegi di un certo tipo su un sistema operativo per insediare un rootkit a livello hardware non si può usare la stessa procedura a fin di bene su un sistema sano per renderlo sicuro con una patch del produttore della CPU?

Perché l'articolo sembra dire così ma poi ho letto la discussione e mi è venuto qualche dubbio a riguardo... :fagiano:

@bobafetthotmail: da una lettura veloce pareva il contrario :doh:


Devi per forza smontare il chip del bios e usare un programmatore EEPROM.

Se entra dentro qualche altro componente della scheda madre (altri dispositivi hanno spazio per firmware e roba varia) che fai? Dissaldi pezzi?
mi viene in mente come unica soluzione quella adottata da Turturro nei Transformers quando ne bruciava uno col lanciafiamme. non trovo la clip, peccato

non si può usare la stessa procedura a fin di bene su un sistema sano per renderlo sicuro con una patch del produttore della CPU?
Sì, ma ti chiudi fuori e non permetti aggiornamenti ulteriori al microcode, come detto sopra non cè alcuna garanzia che questa falla nel microcode sia l'ultima (anzi).

Se fai una roba simile per patchare + chiudere fuori gli altri ma che permette gli aggiornamenti tramite sistema suo devi farlo SICURO sennò anche quello può diventare una falla. Perchè stai pur certo che tutti quelli interessati (spionaggio politico e industriale, hacker di alto livello, specialisti di sicurezza coi maroni) si smeneranno parecchio per craccartelo.

Personalmente preferisco il sistema della memorietta dedicata col tastino hardware, che se non arriva qualcuno e manomette la macchina fisicamente, col cazzo che un rootkit del genere si installa nella scheda madre.

Ma comunque diciamocelo... Che interesse ha Intel a farlo? :rolleyes:

per la precisione l'articolo originale dice "need to have kernel or system privileges on a computer"

non è raro trovare in circolazione malware che girano con quel livello di privilegio

il problema imho è che si sta mettendo troppa roba "lato hardware", creando una superficie d'attacco notevole, in zone la cui esistenza è sconosciuta all'utente medio e dove gli antivirus non possono mettere mano

e onestamente non comprendo il perchè si stia procedendo in questa direzione
In realtà questo esempio dimostra l'esatto contrario: che, per rendere più semplici (da implementare e funzionare) alcune cose, si preferisce spostare lato software qualcosa che sarebbe complicato realizzare interamente lato hardware.

Poi è chiaro che parliamo di roba di cui nemmeno l'utente più scafato sia a conoscenza, visto che è roba a cui soltanto alcune realtà hanno accesso e/o sono coperte da trade secret et similia.

mica tanto, vuol dire che una vola infettato devi buttare la cpu perchè si è installato nel firmware. Sempre che te ne accorga, perchè a quel punto non è più rilevabile.
Mi puzza tanto di nsa...
Come diceva coso, come si chiama... sbaffo, mi sa tanto che sia una falla governativa. Magari non e' una falla di design, puo' essere davvero non voluta, ma credo che alla NSA e non solo lo sapessere quasi fin dalle origini.
E va a sapere cosa abbiamo al giorno d'oggi nei nostri dispositivi.
E' una falla di quasi VENTI anni fa, di un limitato numero di processori. Infatti è stata poi eliminata: senza il "permesso" di NSA?

Il complottismo NON è il profumo della vita...

appunto

diranno che "non è facile trovare ed usare vulnerabilità in quel codice", ma poi quando se ne trova una è una strage
Mi sembra ovvio che lo si dica, com'è ovvio che non esiste alcuno strumento che, data una qualunque applicazione, sia in grado di determinare se questa sia fallata o meno.

Questo non sono io a dirlo, ma un ben noto Teorema (quindi non teoria né opinione personale, per chi conosce il significato di questa parola) che si studia (e, ovviamente, si dimostra) nella Teoria della computabilità. Quindi non è roba che si trova nei forum frequentati da tuttologi internettiani.
e ovviamente quel tipo di memorie non può essere a sola lettura, proprio perchè può essere necessario dover aggiornare il codice
Esattamente. Perché aggiornare il firmware col nuovo microcodice è di gran lunga più semplice e infinitamente più economico della realizzazione di un nuovo step per il processore. Il famigerato Pentium bug penso che abbia insegnato qualcosa, no?
come accade col software "normale" insomma, con la differenza che questo software qui è opaco, sconosciuto ai più, ficcato in posti difficilmente accessibili, ecc...
Esattamente dove e come dovrebbe essere, visto che si tratta di roba altamente specializzata nonché delicata. Non mi pare che lavorare con BIOS/UEFI, e firmware in di questo tipo generale, sia appannaggio di normali programmatori/ingegneri, e non v'è alcun motivo per cui dovrebbe esserlo.
ma loro arriveranno e ci diranno "ecco perchè vogliamo criptare tutto e ficcarvi il tpm ovunque", solo che la storia dimostra che le chiavi usate per questi scopi hanno la tendenza a farsi rubare
Il TPM, e il trusted computing in generale, non c'entra con tutto ciò.

Ma è apprezzabile, e ha i suoi pregi tanto per gli utenti quanto per gli sviluppatori. Ovviamente non è apprezzato dagli scrocconi o da chi vorrebbe mettere facilmente mano sul lavoro degli altri, ma di questi energumeni possiamo benissimo infischiarcene.
mah, sarò complottista, però a me sembra che gli unici a guadagnarci da tutta questa charade siano gli spioni
Gli spioni guadagnano da ogni cosa possa portare vantaggi per il loro lavoro, ed è lapalissiano.

Il codice, per sua natura, è soggetto a bug e non c'è modo di verificare con assoluta certezza che ne sia esente (vedi teorema di cui sopra). Per cui è chiaro che se ne avvantaggino, una volta messo le mani su qualche bug utile per il loro lavoro.

La soluzione finale in questo caso è altrettanto lapalissiana: fare a meno del codice.

Ma magari a un complottista come te va benissimo così...

...la possibilità di "variazione" delle routine del microcodice per le cpu Intel x86 fu introdotta all'indomani del famosissimo bug nell'algoritmo SRT delle fpu dei processori Pentium...
Con il possente Pentium PRO...la cui fpu fu verificata in modo "molto esaustivo".
Se non mi ricordo male comunque il S.M.M fu introdotto con l'80386SL che era destinato ai computer portatili.

E' ovvio che "gente" come NSA ed anche ciò di cui non si conosce nemmeno l'esistenza sappiano con eoni di anticipo di questi problemi.
Molti dei quali potrebbero essere anche desunti dagli errata pubblicati dai produttori di cpu.

Marco71.
Non ho idea se l'NSA o un altro ente governativo possa essere a conoscenza di questa falla, e in generale del microcodice utilizzato da Intel (che ovviamente cambia a seconda dei processori).

Ma è certo che Intel se lo tenga molto ben stretto, il suo microcodice: non è roba che si trova in giro. ;)

questo punto mi chiedo se è possibile fixare la falla con un aggiornamento firmware rilasciato da Intel.
Ma mi sembra di capire che non sia possibile a meno di non sostituire il processore con uno recente...
Dovrebbe bastare un aggiornamento del firmware, esattamente come avviene quando si rilascia un nuovo processore che potrebbe funzionare sulla scheda madre che hai acquistato, ma il cui BIOS/UEFI non riesce a riconoscerlo correttamente e caricargli il firmware col microcodice più aggiornato.

Se vedi nei siti di produttori di schede madre, alcune volte nella descrizione del nuovo BIOS/UEFI c'è scritto: "introdotto supporto al nuovo processore XYZ".

paghi tu o chi è responsabile della falla?
The software is provided as is.
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.
Il solito fantacomplottismo spicciolo...
Cmq i sistemi linux possono installare loro microcode. Se ciò previene da rischi si passi ai sistemi linux.
Tranquillo, giovane padawan linuxaro: è un problema generale.
Spero che qualcuno faccia cause milionarie.
Aspetta e spera. :D

quind i firmware delle cpu possono essere aggiornati?
Sì: vedi anche i precedenti commenti.
nel caso perchè intel non rilascia tali aggiornamenti? e cosa indicherebbe la presenza del malware!?
Intel rilascia aggiornamenti dei firmware dei suoi processori. Nello specifico, SE ha senso farlo, non vedo perché non dovrebbe.

Ho capito molto poco, ma penso di aver capito la sostanza.
Se qualcuno riesce a sfruttare questo bug ottiene privilegi che neanche l'amministratore ha, quindi può agire completamente indisturbato visto che nessun antivirus è in grado di riconoscerlo, può agire a basso livello e in completo anonimato.
L'SMM lavora a livello di privilegio -2: il più elevato in assoluto, e superiore anche a quello Hypervisor (-1). Puoi chiamarlo "God mode". :D
Scusate, ma questa non sarebbe una falla da sistema operativo che normalmente si chiude con un bugfix negli aggiornamenti, questo è proprio un errore madornale progettuale del processore, a cui non c'è rimedio se non cambiando PC, e sticazzi...
E' una falla, esattamente come può capitare con qualunque software, e che è venuta fuori dopo diversi anni (e innumerevoli code review): dunque tutt'altro che "madornale".

Poi, come già detto, non si può prevedere se un software abbia o meno bug. Vedi precedente commento sull'argomento.

VMBRs operate in protected mode with paging enabled,
while SMBRs operate in a 16 bit environment similar to Real Mode without
paging. Finally, both VMBR’s and SMBR’s can be classified as
non-persistent rootkits. Non persistent rootkits exist only in
memory and lack the ability to persist across reboots on the
machine they are installed on. Although on the surface this
seems like a significant disadvantage, when one considers that
many server systems run for weeks or months at a time between
reboots, it becomes less of an issue. Due to the complex nature
of the SMBR, it is unlikely that such a rootkit will appear on the
more frequently rebooted systems (e.g. home user machines)
anytime soon.

Se ho compreso bene spento il computer la minaccia muore... quindi il problema è che se hai il file d'origine che lo carica lo ricarichi, ma a questo punto dovrebbe essere il file di origine rintracciabile come rootkit da un software anti-rootkit.

Solo per capire: paging sarebbe la funzione NX o XD!?
No. La paginazione viene usata per suddividere logicamente la memoria in blocchi di (in genere) eguale dimensione (dimensione della pagine).

NX e XD, invece, è un flag per una specifica pagina che impedisce l'esecuzione di codice proveniente da essa. Serve a evitare di sfruttare falle di buffer overflow con annessa possibilità di eseguire il codice iniettato in quella porzione di memoria.

Ho letto più o meno tutti i post che avete scritto e da ciò mi è sorta una domanda: se la falla può essere sfruttata da un malware che ha privilegi di un certo tipo su un sistema operativo per insediare un rootkit a livello hardware non si può usare la stessa procedura a fin di bene su un sistema sano per renderlo sicuro con una patch del produttore della CPU?

Perché l'articolo sembra dire così ma poi ho letto la discussione e mi è venuto qualche dubbio a riguardo... :fagiano:
Un sistema è sicuro... finché non si trova una falla che non lo rende più tale. :D

Dunque i produttori di CPU lavorano per fornire un sistema sicuro già in partenza. :)

Poi i bug sono imprevedibili per loro natura: vedi gli altri commenti. ;)

cmq è specificato dagli analisti che il rootkit non è persistente e che nel caso operi, è sufficiente l'ibernazione ad eliminare l'eventuale minaccia (Se presente).

L'elaborazione della minaccia è particolarmente complessa e coinvolge altri tipi di malware tipo keylogger. Se il keylogger opera nel caso è sufficiente verificare l'uscita di pacchetti nel momento in cui si digiti da tastiera. Il malware non è ritenuto pericoloso per l'utente comune che spegne ed accende la macchina, piuttosto è pericoloso per server e mainframe.

Altro aspetto: se non si intende essere "spiati" etc... bisogna evitare internet: i pacchetti viaggiano, si trasmettono non solo da un ip all'altro, ma anche da un mac address all'altro adiacente con incapsulamenti vari.

Infine, come il complottismo è sbagliato anche l'estremo opposto lo è: si definisce superficialità, o incapacità deduttivo logica.

epilogo: se si attende che il FUD (terrorizzare l'utenza) sia metodo efficacie per modificare comportamenti ricattando, si finirà molto male... e l'SMMR e consimili diverranno l'ultimo dei problemi "esistenziali" di cui preoccuparsi.

(significherà iniziare a fare liste di soggetti e loro siti che puzzano... di marketing becero).

Il nocciolo della questione, che poi è ciò che ho detto nei precedenti commenti, è che ciò di cui abbiamo parlato finora fa parte della normale natura del software. Con bug o falle che si voglia, bisogna conviverci.

Ciò non vuol dire che si debba minimizzare le problematiche, sia chiaro. Ma bisogna capire che... sono cose che capitano. Pur con tutta la buona volontà e professionalità che ci si possa mettere nello scrivere il codice.

Tutto qui.

cmq è specificato dagli analisti che il rootkit non è persistente e che nel caso operi, è sufficiente l'ibernazione ad eliminare l'eventuale minaccia (Se presente).Se il rootkit è solo nella ram (SMM è ram) basta un riavvio, questa è la scoperta dell'acqua calda. Quella cosa lì era che dei bios vecchi non settano la SMM come non scrivibile all'avvio.

Il punto è che è abbastanza difficile che un rootkit che richiede di avere privilegi kernel o OS per essere installato (quindi che ha già compromesso in modo più o meno irreparabile l'OS) poi esista solo nella ram e quindi quando riavvi sparisce.

epilogo: se si attende che il FUD (terrorizzare l'utenza) sia metodo efficacie per modificare comportamenti ricattando l'utenza si finirà molto male..Come già detto, se neanche tu che un pò sei interessato comprendi l'entità della minaccia senza forte assistenza dall'esterno, figurati il 99.9999% dell'utenza.

Ergo usare questi mezzucci come marketing è fondamentalmente... inutile, quindi non lo fanno per quello. è solo per ridurre i costi.

E' una falla di quasi VENTI anni fa,Rimasta presente fino ai prodotti del 2010. non sono 20 anni fa il 2010.

Un sistema è sicuro... finché non si trova una falla che non lo rende più tale.
Dunque i produttori di CPU lavorano per fornire un sistema sicuro già in partenza. Logic fail.
Spiega perchè la prima frase dovrebbe giustificare la seconda, sennò non metterci "dunque".