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

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 pubblicata il , alle 08:25 nel canale Sicurezza
Intel
 
113 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Norskeningia18 Luglio 2008, 09:42 #51
Originariamente inviato da: DVD_QTDVS
dipende dal bug..
qualsiasi 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 ?


Ehm peccato che nel caso dei microprocessori il "codice" e' fatto di transistors xD

difficile "flasharli"
Octane18 Luglio 2008, 10:48 #52
Originariamente inviato da: Norskeningia
Ehm peccato che nel caso dei microprocessori il "codice" e' fatto di transistors xD

difficile "flasharli"


non direi..il [B]microcodice[/B] serve infatti allo scopo di ri-programmare alcune funzioni della CPU al boot del sistema. Viene caricato con il BIOS e spesso ne viene fatto un ulteriore override da parte del sistema operativo.
Chukie18 Luglio 2008, 11:26 #53
Non ho trovato nessuna reazione online da parte delle società di sicurezza, solo un commento da parte di Prevx.

Recently, some articles have been published after Hack in the Box Security Conference 2008 presentations have been revealed. One of the most interesting topics that will be shown at the conference will be the presentation given by Kris Kaspersky.

Kaspersky (who has nothing to do with Kaspersky Labs) will be presenting his research and proof of concepts on how to exploit Intel CPU bugs to make an attack regardless of the operating system or if applications installed are all updated or not...


http://www.prevx.com/blog/97/CPU-Bu...-necessary.html
Ray_of_Light18 Luglio 2008, 11:47 #54
Se è possibile condurre un "attacco" usando javascript o pacchetti forgiati, ed indipendentemente dall'OS utilizzato, mi sembra evidente che il problema sia legato agli algoritmi di esecuzione "out of order" quando eseguiti su un dual core.
Tuttavia c'è una grande differenza tra il dimostrare una vulnerabilità e utilizzarla per effettuare un attacco.
Vedremo.

Antonio

LukeHack18 Luglio 2008, 12:11 #55
non ci vedo nulla di clamoroso, se esistono dei bachi legati all'architettura, nel fatto che sia possibile sfruttarli in locale...
ed ottenere per es. un classico buffer overflow...
mdannib18 Luglio 2008, 12:33 #56
Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.
Discorso analogo per i pacchetti TCP.....è lo strato kernel che li "trasforma" ed esegue il linguaggio macchina.
Aggiungo anche che dubito che la JVM e lo strato kernel TCP sia scritti direttamente in assembler ma saranno scritti in C/C++; quindi c'è un altro livello di sicurezza dato dal compilatore che non dovrebbe generare codice che possa incorrere nei bug della cpu.

Ciao
/Matteo
LukeHack18 Luglio 2008, 12:44 #57
Originariamente inviato da: mdannib
Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.

e chi l'ha detto che lo sia?
mjordan18 Luglio 2008, 12:46 #58
Originariamente inviato da: mdannib
Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.
Discorso analogo per i pacchetti TCP.....è lo strato kernel che li "trasforma" ed esegue il linguaggio macchina.
Aggiungo anche che dubito che la JVM e lo strato kernel TCP sia scritti direttamente in assembler ma saranno scritti in C/C++; quindi c'è un altro livello di sicurezza dato dal compilatore che non dovrebbe generare codice che possa incorrere nei bug della cpu.

Ciao
/Matteo


Caro Matteo, prima di fare lo sbruffone e contestare qualcuno che per raggiungere intellettualmente dovresti vivere ancora 6 o 7 vite (ma io sono sicuro che nemmeno ti bastano), per lo meno accertati delle differenze che ci sono fra Java e JavaScript. Perchè lui parla di JavaScript, non Java, che sono due cose totalmente diverse. Piu' modestia (o maggiore attenzione e comprensione nella lettura delle news).
Tra l'altro il tuo discorso fa ancora acqua, perchè se alcuni bug non sono stati documentati o lo sono stati da poco, stai tranquillo che nessun compilatore è in grado di evitarli, per lo meno nell'immediato.
Chukie18 Luglio 2008, 12:50 #59
Originariamente inviato da: mdannib
Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.
Discorso analogo per i pacchetti TCP.....è lo strato kernel che li "trasforma" ed esegue il linguaggio macchina.
Aggiungo anche che dubito che la JVM e lo strato kernel TCP sia scritti direttamente in assembler ma saranno scritti in C/C++; quindi c'è un altro livello di sicurezza dato dal compilatore che non dovrebbe generare codice che possa incorrere nei bug della cpu.

Ciao
/Matteo


Questo signore ha scritto svariati libri ed è un rinomato esperto del settore. Tu chi sei? Per permetterti di essere così sbruffone dovresti almeno avere un'esperienza nel settore pari o superiori a costui.

Non commento il resto perché hai sparato una serie di balle spaziali alle quali, giustamente, solo chi non ha facoltà di comprendere appieno la serietà del problema può credere.
Octane18 Luglio 2008, 12:50 #60
Originariamente inviato da: LukeHack
non ci vedo nulla di clamoroso, se esistono dei bachi legati all'architettura, nel fatto che sia possibile sfruttarli in locale...
ed ottenere per es. un classico buffer overflow...


la cosa che mi rende dubbioso e' che ha dichiarato che e' possibile violare la macchina con lo stesso attacco indipendentemente dal sistema operativo (che quindi hanno gestioni dei processi e della memoria completamente differenti).
Un buffer overflow quindi non avrebbe necessariamente lo stesso risultato su due OS diversi.
« Pagina Precedente     Pagina Successiva »

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

La discussione è consultabile anche qui, sul forum.
 
^