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

Nesssuno, è solo una mia supposizione.
Infatti aspetto con impazienza il mese di ottobre per scoprire se riesce a fare quello che ha detto.

Ripeto per arrivare all'assembler (che è l'unico linguaggio che probabilmente può scatenare i bug delle cpu) partendo dai javascript c'è un "mondo" di software in mezzo.....dubito che siano bacati la jvm, i driver tcp, il kernel ed i compilatori con cui questi software sono stati fatti.

Mandare in overflow una applicazione è una cosa ben diversa rispetto a sfruttare bug delle cpu e sicuramente è fattibile anche con javascript...

Prima di tutto grazie per lo sbruffone, però cerchiamo di capirci.
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.

Aridaje co sto Java... Hai semplicemente detto che il tizio ha detto un mucchio di sciocchezze. I bug in questione presi dal ricercatore sono appunto bug sfruttabili a prescindere dagli strati software coinvolti.

Prima cosa leggete l'intervista della persona quì

riporto una parte di ciò che ha detto :
"Some of the bugs that will be shown are exploitable via common instruction sequences and by knowing the mechanics behind certain JIT Java-compilers, attackers can force the compiler to do what they want (for example: short nested loops lead to system crashes on many CPUs)."

capito?!....Sfruttando alcuni compilatori java posso forzarli a generare sequenze di codice che mandano in crash il sistema....
Che dietro alla parola "certain" si nasconda buchi del software mi piacerebbe saperlo, piuttosto che sparare il messaggio marketing che preoccupa tutti i possessori di pc intel-based.

sbagliato post

Il mio parere..

Raga.. la situazione può diventare alquanto seria.. e cmq.. un fondo di verità, credo ci sia.. eccome, se c'è! Certo, alla fine, nn credo ke queste persone ke hanno queste capacità, se la possono prendere con un pc desktop ke contenga qualche file.. o qualche immagine persona, ma a livello di business.. la cosa comincia a farsi molto ma molto + seria, specie nelle grandi reti di pc.. in posti dove, c'è un giro d'affari abbastanza elevato. Certamente, è anche lecito pensare al fatto ke, ki comincia, nn si butterà mai su una banca o farà danni ad un'azienda.. con il rischio d essere chiuso dentro dopo qualche mese..

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.

il buffer overflow è a livello dei registri, non della memoria gestita dall'OS.
è possibile invece eccome sfruttare una falla di questo tipo, a prescindere dagli OS. basta sapere quale registro caricare, che payload inserire e il gioco è abbastanza facile.. certo il proof of concept magari non avrà lo stesso sorgente per ogni OS, però il comportamento desiderato sarà lo stesso..

Luke, scusami, ma il buffer overflow non si genera "caricando" dei registri per poi svaccare una area di memoria ben definita (stack e/o heap) per eseguire del codice arbitrario (se modifico lo stack posso inserirgli un indirizzo di memoria di ritorno, che viene caricato nel registro EBP, e quindi fare eseguire il codice che voglio io...) ?

e' molto che non programmo in assembly, ma gli errata segnalati http://download.intel.com/design/processor/specupdt/318733.pdf"]qui[/URL] includono anche scritture errate in memoria (valori o indirizzi)
resto invece d'accordo con te che una volta avuto accesso per l'esecuzione del payload il gioco e' fatto.

Attenderemo gli sviluppi.
Ad ogni modo, chissa' che questa dimostrazione serva ai produttori di CPU per costringersi a concentrarsi di piu' sulla qualita' ed affidabilita' dei propri prodotti piuttosto che sulle mere frequenze di esercizio.

si.