E' possibile sfruttare i bug della CPU per attaccare un sistema?

Un ricercatore ha affermato di poter sfruttare alcuni bug presenti nelle CPU Intel per sferrare attacchi in locale o da remoto. Ad ottobre la dimostrazione pratica
di Fabio Gozzo pubblicata il 17 Luglio 2008, alle 08:25 nel canale SicurezzaIntel
113 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoqualsiasi istruzione che provoca l'azzeramento o il controllo dei flag di segmento protetto,
può dare il controllo totale al programma..
Oramai anche le CPU dovrebbero avere una flash x l'upgrade del codice..
che qualcuno si riserva una porta di accesso remoto ? magari anche non documentata ?
veramente "l'upgrade del codice" è previsto sin dai tempi del pentium pro
allora:
1) Intel rilascia periodicamente degli aggiornamenti per il microcode della CPU, basta caricarli ad ogni avvio (e la cosa si può fare solo con linux) per avere una CPU "senza" bug.
2) qualora si riuscissero a sfruttare i bug, la tua CPU non sarebbe da buttare!!!!! Qualcuno potrebbe solo prendere il controllo del tuo PC.
3) I firewall potrebbero adattarsi per prevenire questo tipo di attacco. Non un "firewall della cpu", un "firewall e basta". L'attacco, per quanto scritto nella news, consisterebbe in pacchetti TCP configurati ad hoc. Riconoscere e scartare i pacchetti è proprio quello che, per sommi capi, fa un firewall.
Non stò denigrando nessuno e non stò dicendo che non sia "bucabile" nessuno dei sistemi citati. Stò solo cercando di dire che per arrivare ed eseguire il microcodice bacato su una cpu partendo da uno script java c'è una pila di software molto lunga.
O tutto il software che c'è sopra al microcode bacato delle cpu è scritto IGNORANDO questi bachi oppure la vedo molto ma molto difficile.
Mi sembra che siamo in un paese libero e ognuno possa esprimere le proprie opinioni; non mi sembra di aver insultato nessuno.
ti spiego..Innanzitutto quello di cui stai parlando tu è JAVA, un linguaggio pseudocompilato che ha bisogno della java virtual machine per funzionare..javascript è un linguaggio interpretato che necessita solo di un browser compatibile. Ti hanno detto che stai dicendo un mucchio di scemenze perché non serve che tutti i software da te citati siano buggati (questo senza nulla togliere al fatto che sicuramente lo sono perché nessun programma è immune dai bug)..se l'attacco consiste realmente in pacchetti configurati ad hoc in grado di sfruttare i bug della cpu, sarebbe indipendente dai software installati e dal sistema operativo; per portare avanti l'attacco sarebbe potenzialmente necessario solo un computer collegato ad internet con una CPU buggata.
La cosa comunque non mi sorprende affatto..
P.S.: si scrive sto, non stò
http://downloadcenter.intel.com/Det...x*&lang=eng
questo è per i p4, se scorri la pagina ci sono i microcode anche per gli altri processori..devi copiarlo in /etc/firmware ed il kernel dev'essere configurato per caricarlo (c'è un opzione apposta)
non mi sembra che la CPU abbia una memoria flash..
L'attenzione maggiore, (a prescindere dal fatto ke.. questi attacchi siano praticabili o meno, da un numero piuttosto numerabile di gente..), va cmq a tutte queste cpu low cost con cache ridotta.. ke.. a mio avviso, oltre alla cache, x essere destinati al low cost, sicuramente in fase di progettazione è probabile ke x rientrare nella fascia, abbiano + bag di una cpu ke costa il doppio o il triplo.. e infatti NON A CASO.. QUESTE CPU.. NN INCLUDONO NE LA VT E NEPPURE LA TXT.. tecnologie, atte cmq, a limitare questo tipo di problemi con il criptaggio dei dati.. e con altri controlli ke invece sono racchiuse in quelle cpu dove queste tecnologie sono presenti e ke cmq, possono definirsi "di prima scelta".
X quanto riguarda i vecchi computer.. penso ke possiamo stare + tranquilli.. xché ki sviluppa questo tipo d'attacco, mira a colpire quante + macchine possibili, e nn di certo, attenzionerebbe la sua bravura nel colpire una macchina da 20-30 euro.. adibita al download o cmq, a compiti futili.. ke anche quando venissero interrotti, nn accadrebbe da parte dell'utente nessuna drastica perdita di dati.. e x lo + nn farebbe neanche tanto clamore: figuriamoci se una skermata blu x esempio.. su un pIII poteste destare a sospetti di un attacco di questo tipo.. in quanto potrebbe essere qualsiasi componente a generare quel tipo di errore, comunissimo ma nn insolito in macchine con i loro 8-10 anni di vita sulle spalle..
Stessa cosa vale x Amd.. Se oggi x oggi.. Intel detiene l'80% della fetta di mercato mondiale.. è + a rischio e vulnerabile di Amd ke ne detiene solo il 20%.. e ke cmq, prende acqua da tte le parti.
In ogni caso, staremo a vedere le dimostrazioni, ma cmq, x quanto mi riguarda.. nn c'è niente di banale o di strano e credo ke IL TUTTO sia fattibile o possibile.. e siamo ben lontani dal pensarlo come pensiero futuristico o fantascientifico. Bye.
TXT e VT non neutralizzano i bug software.. che sono comuni sia su Cpu Palladium che Cpu non Palladium
la procedura, per sommi capi, è quella che ti ho descritto:
1) scarichi il microcode
2) lo copi in /etc/firmware
3) basta!
ovviamente il kernel dev'essere predisposto per caricare il microcode..se non lo è dovresti ricompilarlo (se non l'hai mai fatto dovresti cercare una guida su google...basta scrivere ricompilazione del kernel e ti esce una pletoria di siti).
In particolare dovresti solo selezionare un opzione "microcode support on intel ecc. ecc." o qualcosa del genere..dovrebbe stare nella scheda di configurazione del processore (dove ti chiede di selezionare la famiglia di processori tanto per intenderci), non puoi sbagliare!
OVVIAMENTE, non si tratta di una memoria flash...è qualcosa di molto più complesso. Il microcode comprende delle istruzioni ad un livello più basso dell'assembly (devono appunto definire il comportamento delle istruzioni assembly) che vengono caricate in una memoria ad alta velocità integrata nel processore.
Infatti le istruzioni a basso livello, anche le più elementari, coinvolgono altre istruzioni, ancora più elementari.
Su http://en.wikipedia.org/wiki/Microcode viene riportato un esempio per capire meglio il funzionamento di queste operazioni.
"For example, a single typical microinstruction might specify the following operations:
* Connect Register 1 to the "A" side of the ALU
* Connect Register 7 to the "B" side of the ALU
* Set the ALU to perform two's-complement addition
* Set the ALU's carry input to zero
* Store the result value in Register 8
* Update the "condition codes" with the ALU status flags ("Negative", "Zero", "Overflow", and "Carry"
* Microjump to MicroPC nnn for the next microinstruction"
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".