[Thread Ufficiale] Tecnologie LaGrande e Presidio nei processori Intel e AMD

[Alex_80]

Originariamente inviato da ConteZero

Questo fa parte del regno delle leggende metropolitane.
Un virus che sfrutta la VT per funzionare deve sfruttare la VT. La virtualizzazione significa "lanciare qualcosa in una macchina virtuale", quindi il virus dev'essere l'hypervisor... ergo dev'essere eseguito PRIMA del SO sottostante.

Io uso macchine virtuali software tramite VirtualPC e VirtualBox, però non conosco in modo approfondito il funzionamento di una macchina virtuale software, ancora meno di una macchina virtuale hardware che sfrutta la VT, perciò da qui i miei dubbi sulla sicurezza.

In particolare il mio dubbio è che con una virtualizzazione hardware, invece che software, una volta che un virus ha creato una macchina virtuale (nel caso riesca a superare l'antivirus per crearla), quella macchina è invisibile al PC reale e quindi l'antivirus si accorgerebbe soltanto degli attacchi ma non potrebbe eliminare il virus?

Potresti spiegarmi o indicarmi un link in cui venga spiegato, in modo semplice ma approfondito, il funzionamento di una macchina virtuale software e hardware tramite VT?

[malocchio]

Originariamente inviato da Alex_80

Io uso macchine virtuali software tramite VirtualPC e VirtualBox, però non conosco in modo approfondito il funzionamento di una macchina virtuale software, ancora meno di una macchina virtuale hardware che sfrutta la VT, perciò da qui i miei dubbi sulla sicurezza.

In particolare il mio dubbio è che con una virtualizzazione hardware, invece che software, una volta che un virus ha creato una macchina virtuale (nel caso riesca a superare l'antivirus per crearla), quella macchina è invisibile al PC reale e quindi l'antivirus si accorgerebbe soltanto degli attacchi ma non potrebbe eliminare il virus?

Potresti spiegarmi o indicarmi un link in cui venga spiegato, in modo semplice ma approfondito, il funzionamento di una macchina virtuale software e hardware tramite VT?

Anche io sarei interessato a questi argomenti... non mi sono mai documentato sulla virtualizzazione hardware, pensavo fossero solo delle istruzioni in più del CPU che se eseguite rendono più facile (= più veloce) la virtualizzazione, rispetto a quella ricreata a più alto livello.

Che discorso incasinato, non mi capisco neanche io...

[ConteZero]

Il "virus" su VT ha qualche senso solo se di per sé non è altro che un hypervisor.
In pratica dovrebbe essere un piccolo cosino che crea una macchina virtuale (all'avvio, prima dell'esecuzione di windows) e che "esegue" windows dentro la macchina virtuale.
In questo modo tutto quello che "gira" dentro Windows è su una macchina virtuale che, ovviamente, non sà di non girare sull'hardware "vero"...

Il discorso di per sé è molto particolare (e non porta da nessuna parte, anche perché un virus su VT è decisamente difficile da teorizzare), in linea di massima il succo è che come un sistema emulato non può "uscire" dalla sua macchina virtuale (ha, cioè, accesso solo a quello che l'hypervisor gli mette a disposizione) così un virus con VT girerebbe indisturbato perché gli antivirus possono "scansionare" solo quello che si trova nell'"ambito" della macchina virtuale su cui girano.

Un virus semplice potrebbe mappare l'hardware di IO in modo 1:1 (così da far si che l'OS abbia accesso normalmente all'hardware) ma si troverebbe nella spiacevole situazione di essere "fuori"... non avrebbe cioè la possibilità di accedere alle API dell'OS.

Visto in questi termini un applicativo simile più che ad un virus sembra assomigliare ad un debugger per OS...

[k0nt3]

@ConteZero
mi sa che sei fuori strada.. non solo sono stati teorizzati, ma ne esiste pure un prototipo funzionante (sia su hardware intel che amd).
non è nemmeno necessario che il virus venga eseguito prima del sistema operativo, può prendere il possesso del sistema a macchina avviata.
mi quoto da solo: http://www.hwupgrade.it/forum/showpo...66&postcount=9

non voglio rovinare l'euforia del momento (la virtualizzazione è molto di moda) però consiglio a tutti la lettura di:
- http://invisiblethings.org/papers/Se...nviroments.pdf
- http://invisiblethings.org/papers/Se...%20RSA2008.pdf

la conclusione è che la virtualizzazione è una bella tecnologia, ma sarebbe opportuno risolvere un paio di "problemini" prima di farla passare per acqua miracolosa

[k0nt3]

Originariamente inviato da ConteZero

Il TPM (Trusted Platform Module) è solo una cornerstone di TCPA (o come diavolo si chiama oggi).
Di per sé il componente non è né buono né cattivo, anzi... in certi contesti può essere anche utile (l'engine crittografico sarebbe utilissimo se si riuscisse ad usare con SSL e soci) e, vale la pena dirlo, buona parte delle feature "avanzate" di TPM sono accessibili solo dietro NDA, per cui su Linux il supporto rimane limitato al minimo sindacale.

mi pare che ci lavori ibm su linux, quindi dubito fortemente che il supporto al tpm sia limitato.

Originariamente inviato da ConteZero

Per concludere nei processori si può mettere di tutto (le safe zone dei dischi IDE/SATA sono almeno altrettanto problematiche e pensate per fini simili, eppure nessuno se ne preoccupa anche perché nessuno le usa) ma alla fine, come sempre, l'utilità e/o la pericolosità la decide il mercato e la gente.

dipende... la gente che "usa" l'informatica in genere è abbastanza ignorante (senza offesa ma è la verità), quindi penso che qualunque cosa venga appioppata al mercato più o meno viene accolta prima o poi.
per questo si cerca di sensibilizzare la gente non informata con video tipo quello che è stato postato prima

[ConteZero]

JBO404

Anyway che esistano dei "prototipi" và anche bene, ma nella pratica è difficile che diventino qualcosa di reale.
Tra l'altro grazie al fatto che solo alcuni processori hanno VT dal punto di vista di un virus writer questa tecnologia è poco interessante.

[ConteZero]

Originariamente inviato da k0nt3

mi pare che ci lavori ibm su linux, quindi dubito fortemente che il supporto al tpm sia limitato.

dipende... la gente che "usa" l'informatica in genere è abbastanza ignorante (senza offesa ma è la verità), quindi penso che qualunque cosa venga appioppata al mercato più o meno viene accolta prima o poi.
per questo si cerca di sensibilizzare la gente non informata con video tipo quello che è stato postato prima

Certo che ci lavora IBM, questo non toglie che buona parte delle tecnologie "interne" ai TPM siano coperte da NDA e che quindi è legalmente impossibile scrivere codice open source che le gestisca.

[walter sampei]

Originariamente inviato da k0nt3

dipende... la gente che "usa" l'informatica in genere è abbastanza ignorante (senza offesa ma è la verità), quindi penso che qualunque cosa venga appioppata al mercato più o meno viene accolta prima o poi.
per questo si cerca di sensibilizzare la gente non informata con video tipo quello che è stato postato prima

ot: la gente purtroppo e' ignorante e basta (e nel branco mi ci metto anch'io ). in TUTTI i campi. e alcuni se ne approfittano alla grande, giocando su questo

[k0nt3]

Originariamente inviato da ConteZero

JBO404

Anyway che esistano dei "prototipi" và anche bene, ma nella pratica è difficile che diventino qualcosa di reale.
Tra l'altro grazie al fatto che solo alcuni processori hanno VT dal punto di vista di un virus writer questa tecnologia è poco interessante.

difficile? semmai è difficile trovare un'arma efficace contro un simile malware.
l'ho chiamato "prototipo" anche se è perfettamente funzionante per il semplice fatto che non è un malware, ma un progetto di una ricercatrice. se qualcuno usasse queste tecniche per realizzare un malware sarebbe molto peggio.
se guardi tra i pc in vendita noterai che la percentuale di CPU con VT è molto alta. questo significa che tra un paio di anni tantissime persone avranno questa tecnologia in casa.
ma anche in caso contrario non mi sembra il caso di minimizzare su un problema reale, cioè esistono alcune problematiche riguardo alla sicurezza sulla virtualizzazione che ancora non sono state risolte.
o dobbiamo aspettare che qualcuno confezioni il suo malware prima di preoccuparci?

Originariamente inviato da ConteZero

Certo che ci lavora IBM, questo non toglie che buona parte delle tecnologie "interne" ai TPM siano coperte da NDA e che quindi è legalmente impossibile scrivere codice open source che le gestisca.

puoi postare dei riferimenti? io conosco solo queste specifiche https://www.trustedcomputinggroup.org/specs/TPM/

ps. come spieghi il fatto che ATI rilasciò anni fa specifiche sotto nda riguardanti i suoi chip r200 e ne fecero un driver opensource per linux?

[k0nt3]

Originariamente inviato da walter sampei

ot: la gente purtroppo e' ignorante e basta (e nel branco mi ci metto anch'io ). in TUTTI i campi. e alcuni se ne approfittano alla grande, giocando su questo

quoto in pieno, per questo ignorante era senza offesa.
nell'informatica è particolarmente facile "fregare" la gente che non se ne intende

[walter sampei]

Originariamente inviato da k0nt3

quoto in pieno, per questo ignorante era senza offesa.
nell'informatica è particolarmente facile "fregare" la gente che non se ne intende

ovunque, non solo l'informatica... soprattutto dove ci sia un minimo di tecnologia o scienza. ho a che fare quotidianamente per hobby col settore pesca (e quindi quel che ne e' collegato, come ambiente ecc)... e spesso vedo, sento e leggo cose al limite dell'eresia

in italia si punta tantissimo sul lato umanistico, lasciando le persone molto carenti dal punto di vista scientifico. IMHO non e' casuale.

[Alex_80]

La virtualizzazione hardware per essere eseguita su CPU Intel è obbligatoria la Intel VT?
Con la virtualizzazione hardware la macchina virtuale può essere creata prima di avviare il sistema operativo reale?
Nella virtualizzazione software ci sono gli stessi problemi a individuare un virus che ha creato una macchina virtuale per nascondersi?

Originariamente inviato da ConteZero

Il "virus" su VT ha qualche senso solo se di per sé non è altro che un hypervisor.
In pratica dovrebbe essere un piccolo cosino che crea una macchina virtuale (all'avvio, prima dell'esecuzione di windows) e che "esegue" windows dentro la macchina virtuale.
In questo modo tutto quello che "gira" dentro Windows è su una macchina virtuale che, ovviamente, non sà di non girare sull'hardware "vero"...

Il discorso di per sé è molto particolare (e non porta da nessuna parte, anche perché un virus su VT è decisamente difficile da teorizzare), in linea di massima il succo è che come un sistema emulato non può "uscire" dalla sua macchina virtuale (ha, cioè, accesso solo a quello che l'hypervisor gli mette a disposizione) così un virus con VT girerebbe indisturbato perché gli antivirus possono "scansionare" solo quello che si trova nell'"ambito" della macchina virtuale su cui girano.

Un virus semplice potrebbe mappare l'hardware di IO in modo 1:1 (così da far si che l'OS abbia accesso normalmente all'hardware) ma si troverebbe nella spiacevole situazione di essere "fuori"... non avrebbe cioè la possibilità di accedere alle API dell'OS.

Era quello che intendevo, per quanto riguarda l'impossibilità di uscire dalla macchina virtuale ho qualche dubbio, visto che su una macchina virtuale si possono condividere cartelle dell'hard disk reale e vedere il PC reale come un PC di una LAN: ricordiamo che il virus potrebbe essere l'hypervisor o comunque costringere l'hypervisor a fare quello che vuole lui.

Originariamente inviato da k0nt3

@ConteZero
mi sa che sei fuori strada.. non solo sono stati teorizzati, ma ne esiste pure un prototipo funzionante (sia su hardware intel che amd).
non è nemmeno necessario che il virus venga eseguito prima del sistema operativo, può prendere il possesso del sistema a macchina avviata.
mi quoto da solo: http://www.hwupgrade.it/forum/showpo...66&postcount=9

Molto interessante, lo sto leggendo, anche se mi servirà un po' di tempo per leggerlo tuttom vista la sua lunghezza.

Originariamente inviato da ConteZero

JBO404
Anyway che esistano dei "prototipi" và anche bene, ma nella pratica è difficile che diventino qualcosa di reale.
Tra l'altro grazie al fatto che solo alcuni processori hanno VT dal punto di vista di un virus writer questa tecnologia è poco interessante.

Per adesso, per quanto riguarda Intel mi sembra che dal Core 2 con FSB a 1066 MHz sia supportata la VT, quindi tutti i processori prodotti negli ultimi 2 anni (eccetto quelli di fascia bassa a 800 MHz e i gli introvabili E8190 ed E7200).

[k0nt3]

@walter sampei
non so perchè ma avevo intuito che avevi a che fare con la pesca sampei

[Mafio]

Originariamente inviato da k0nt3

@walter sampei
non so perchè ma avevo intuito che avevi a che fare con la pesca sampei

[ConteZero]

Già immagino i primi virus che danno un errore di "CPU non supportata".
Per il resto una cosa è avere, in laboratorio, un qualcosa che funziona, un altra è farne un virus reale (che sia nascondibile, che non occupi mega e mega e via dicendo)... e poi sai, se un tool mi diventa hypervisor come minimo il sistema "virtualizzato" non può diventare hypervisor... e questo è facile da "detectare".
Per le CPU supportate c'è da dire che la virtualizzazione hardware di Intel è diversa (a quel che so) da quella di AMD come implementazione, e questo complica le cose, ed il fatto che il SO "guest" e quello "base" vedano le stesse cartelle e gli stessi file è fattibile solo se s'installa un qualcosa che metta in comunicazione il SO virtualizzato con l'hypervisor, cosa che non penso sia fattibile in modo "semplice" da un virus che NON vuole essere facilmente detectabile ("Hypervisor bridge driver" non sembra esattamente qualcosa che un antivirus non è in grado di vedere).

Nel dettaglio l'hypervisor non può accedere direttamente alle API dell'OS guest, e questo perché l'OS guest non è "aware" del fatto di essere virtualizzato...
...ovviamente un hypervisor può accedere alla memoria ma non può usare le API dell'OS guest (e questo vuol dire che tutte le funzioni offerte dall'OS guest gli sono precluse) a meno di non installare un qualcosa (che sia un driver o un programma attivo) che faccia da "tramite" e che rediriga le comunicazioni da parte dell'hypervisor.
Stessa cosa per quel che riguarda il filesystem, i filesystem classici non sono pensati per essere usati da due o più "entità" contemporaneamente (montare in scrittura lo stesso filesystem su due macchine è il modo migliore per vedere cosa non si dovrebbe MAI fare) per cui anche le chiamate il lettura o scrittura sul filesystem dovrebbero essere "incanalate" attraverso l'OS guest.
In pratica immaginatevi una stanza con dentro un plastico... un uomo (l'hypervisor) è nella stanza ed osserva il plastico in essa... nel plastico mettiamo delle "mini persone" che sono convinte di vivere in un universo loro... l'hypervisor potrebbe fare tutto quello che vuole nel plastico (spostare mobili, far sentire la sua voce e via dicendo) ma le persone nel plastico non potrebbero interagire con lui perché sono "convinte" che l'universo sia limitato al plastico in cui vivono.
Se l'hypervisor provasse a spostare una persona da una stanza all'altra l'universo del plastico potrebbe entrare in panico (i.e. crashare) perché l'operazione fatta "di forza" dall'hypervisor agirebbe "al di fuori" dei canoni di quell'universo.
Per aggirare il problema nel plastico si mette un "avatar", una persona (quindi un programma o un driver) che agisce per conto dell'hypervisor e che esegue i comandi che gli passa l'hypervisor.
L'unico vero problema è che l'avatar "esiste" nel plastico ed è facilmente identificabile.

Quanto ad ATi e via dicendo da un lato ATi ha iniziato a rilasciare documentazione, dall'altro qualcosa col reverse engineering s'è fatto... ma da lì a supportare ogni minima cosa ce ne vuole.

[Mafio]

Originariamente inviato da ConteZero

Già immagino i primi virus che danno un errore di "CPU non supportata".
Per il resto una cosa è avere, in laboratorio, un qualcosa che funziona, un altra è farne un virus reale (che sia nascondibile, che non occupi mega e mega e via dicendo).
Quanto ad ATi e via dicendo da un lato ATi ha iniziato a rilasciare documentazione, dall'altro qualcosa col reverse engineering s'è fatto... ma da lì a supportare ogni minima cosa ce ne vuole.

[k0nt3]

Originariamente inviato da ConteZero

Già immagino i primi virus che danno un errore di "CPU non supportata".
Per il resto una cosa è avere, in laboratorio, un qualcosa che funziona, un altra è farne un virus reale (che sia nascondibile, che non occupi mega e mega e via dicendo).

lo puoi scaricare qui http://bluepillproject.org/ in un comodo archivio di 100Kb c'è poco da fare gli spiritosi

Originariamente inviato da ConteZero

Quanto ad ATi e via dicendo da un lato ATi ha iniziato a rilasciare documentazione, dall'altro qualcosa col reverse engineering s'è fatto... ma da lì a supportare ogni minima cosa ce ne vuole.

nono.. sto parlando del lontano 2002 quando ATI rilasciò le specifiche di r200 a tungsten graphics sotto nda. il tutto venne usato per produrre un driver opensource. ma qui siamo OT, non ho ancora capito dove hai letto che le specifiche del TPM sono rilasciate sotto nda

[k0nt3]

Originariamente inviato da ConteZero

Nel dettaglio l'hypervisor non può accedere direttamente alle API dell'OS guest, e questo perché l'OS guest non è "aware" del fatto di essere virtualizzato...
...ovviamente un hypervisor può accedere alla memoria ma non può usare le API dell'OS guest (e questo vuol dire che tutte le funzioni offerte dall'OS guest gli sono precluse) a meno di non installare un qualcosa (che sia un driver o un programma attivo) che faccia da "tramite" e che rediriga le comunicazioni da parte dell'hypervisor.
Stessa cosa per quel che riguarda il filesystem, i filesystem classici non sono pensati per essere usati da due o più "entità" contemporaneamente (montare in scrittura lo stesso filesystem su due macchine è il modo migliore per vedere cosa non si dovrebbe MAI fare) per cui anche le chiamate il lettura o scrittura sul filesystem dovrebbero essere "incanalate" attraverso l'OS guest.
In pratica immaginatevi una stanza con dentro un plastico... un uomo (l'hypervisor) è nella stanza ed osserva il plastico in essa... nel plastico mettiamo delle "mini persone" che sono convinte di vivere in un universo loro... l'hypervisor potrebbe fare tutto quello che vuole nel plastico (spostare mobili, far sentire la sua voce e via dicendo) ma le persone nel plastico non potrebbero interagire con lui perché sono "convinte" che l'universo sia limitato al plastico in cui vivono.
Se l'hypervisor provasse a spostare una persona da una stanza all'altra l'universo del plastico potrebbe entrare in panico (i.e. crashare) perché l'operazione fatta "di forza" dall'hypervisor agirebbe "al di fuori" dei canoni di quell'universo.
Per aggirare il problema nel plastico si mette un "avatar", una persona (quindi un programma o un driver) che agisce per conto dell'hypervisor e che esegue i comandi che gli passa l'hypervisor.
L'unico vero problema è che l'avatar "esiste" nel plastico ed è facilmente identificabile.

tutto ciò mi fa capire che non hai letto una riga dei due link che ho postato sopra sulla sicurezza delle VM

[ConteZero]

Beh si, ogni tanto qualcuno viola un RMA e paga milioni di dollari di penale.

Oh, ci sono alcune limitazioni di cui una è quella che "toh, c'è la virtualizzazione attivata" alla quale il reply sembra essere "vabbè, tanto tutti useranno la virtualizzazione, quindi non si potrà detectare da lì".

PS: K0nt3, spiegami una cosa... come fa un hypervisor a scrivere un file su un disco che è gestito dall'OS guest.
Facciamo conto che voglio fare un virus che scrive un file "virus.txt" con dentro "Sei stato infettato" su C:\ nell'OS guest.
L'hypervisor deve prima allocare una pagina in cui mettere il testo ed i dati della syscall... ma come fa a chiedere al memory manager una pagina ? con che process id ? a nome di chi ? ed il memory manager a chi dà la pagina ? a chi "ritorna" la chiamata ?
Poi mette i dati nella pagina (easy) e poi chiama il file manager e gli dice di eseguire la systcall per creare il file e scriverci dentro... ma con che process id ? a nome di chi ? a partire da dove ?
Ovviamente è fattibile, deve costruire un "processo ombra" da usare come tramite, ma quel processo ombra diventa a sua volta un entità "detectabile"... cosa che rende tutta questa discussione un argomento meramente teorico; l'alternativa e passare i dati (e le aree di memoria) di un processo "vittima" a cui "accollare" la colpa dell'operazione, solo che così facendo è più facile crashare qualcosa che cavare un ragno dal buco.
Oh, per la cronaca, l'hypervisor non può direttamente mandare i comandi di scrittura al disco perché non ha idea di quale disco sia C sul guest, di quale sia il filesystem ed in che stato sia il filesystem, cosa che costringe l'hypervisor a dovere necessariamente usare le syscall dell'OS guest... difficile a farsi senza farsi "beccare".

[k0nt3]

non hai capito.. l'hypervisor ha il pieno controllo della CPU, mentre il SO per fare qualsiasi operazione deve passare dall'hypervisor che può intercettare qualsiasi istruzione, manipolarla come vuole e restituire quello che vuole al SO.
leggiti quei pdf che dopo ti sarà tutto più chiaro