| Finalmente la ps3 sarà modificabile..... questo grazie al noto hacker George Hotz, già conosciuto per aver hackerato l'Iphone.... ecco il suo articolo con la relativa traduzione:
George Hotz, previously known as an iPhone hacker, announced that he hacked the Playstation 3 and then provided exploit details. Various articles have been written about this but none of them appear to have analyzed the actual code. Because of the various conflicting reports, here is some more analysis to help understand the exploit.
The PS3, like the Xbox360, depends on a hypervisor for security enforcement. Unlike the 360, the PS3 allows users to run ordinary Linux if they wish, but it still runs under management by the hypervisor. The hypervisor does not allow the Linux kernel to access various devices, such as the GPU. If a way was found to compromise the hypervisor, direct access to the hardware is possible, and other less privileged code could be monitored and controlled by the attacker.
Hacking the hypervisor is not the only step required to run pirated games. Each game has an encryption key stored in an area of the disc called ROM Mark. The drive firmware reads this key and supplies it to the hypervisor to use to decrypt the game during loading. The hypervisor would need to be subverted to reveal this key for each game. Another approach would be to compromise the Blu-ray drive firmware or skip extracting the keys and just slave the decryption code in order to decrypt each game. After this, any software protection measures in the game would need to be disabled. It is unknown what self-protection measures might be lurking beneath the encryption of a given game. Some authors might trust in the encryption alone, others might implement something like SecuROM.
The hypervisor code runs on both the main CPU (PPE) and one of its seven Cell coprocessors (SPE). The SPE thread seems to be launched in isolation mode, where access to its private code and data memory is blocked, even from the hypervisor. The root hardware keys used to decrypt the bootloader and then hypervisor are present only in the hardware, possibly through the use of eFUSEs. This could also mean that each Cell processor has some unique keys, and decryption does not depend on a single global root key (unlike some articles that claim there is a single, global root key).
George’s hack compromises the hypervisor after booting Linux via the “OtherOS” feature. He has used the exploit to add arbitrary read/write RAM access functions and dump the hypervisor. Access to lv1 is a necessary first step in order to mount other attacks against the drive firmware or games.
His approach is clever and is known as a “glitching attack“. This kind of hardware attack involves sending a carefully-timed voltage pulse in order to cause the hardware to misbehave in some useful way. It has long been used by smart card hackers to unlock cards. Typically, hackers would time the pulse to target a loop termination condition, causing a loop to continue forever and dump contents of the secret ROM to an accessible bus. The clock line is often glitched but some data lines are also a useful target. The pulse timing does not always have to be precise since hardware is designed to tolerate some out-of-spec conditions and the attack can usually be repeated many times until it succeeds.
George connected an FPGA to a single line on his PS3’s memory bus. He programmed the chip with very simple logic: send a 40 ns pulse via the output pin when triggered by a pushbutton. This can be done with a few lines of Verilog. While the length of the pulse is relatively short (but still about 100 memory clock cycles of the PS3), the triggering is extremely imprecise. However, he used software to setup the RAM to give a higher likelihood of success than it would first appear.
His goal was to compromise the hashed page table (HTAB) in order to get read/write access to the main segment, which maps all memory including the hypervisor. The exploit is a Linux kernel module that calls various system calls in the hypervisor dealing with memory management. It allocates, deallocates, and then tries to use the deallocated memory as the HTAB for a virtual segment. If the glitch successfully desynchronizes the hypervisor from the actual state of the RAM, it will allow the attacker to overwrite the active HTAB and thus control access to any memory region. Let’s break this down some more.
The first step is to allocate a buffer. The exploit then requests that the hypervisor create lots of duplicate HTAB mappings pointing to this buffer. Any one of these mappings can be used to read or write to the buffer, which is fine since the kernel owns it. In Unix terms, think of these as multiple file handles to a single temporary file. Any file handle can be closed, but as long as one open file handle remains, the file’s data can still be accessed.
The next step is to deallocate the buffer without first releasing all the mappings to it. This is ok since the hypervisor will go through and destroy each mapping before it returns. Immediately after calling lv1_release_memory(), the exploit prints a message for the user to press the glitching trigger button. Because there are so many HTAB mappings to this buffer, the user has a decent chance of triggering the glitch while the hypervisor is deallocating a mapping. The glitch probably prevents one or more of the hypervisor’s write cycles from hitting memory. These writes were intended to deallocate each mapping, but if they fail, the mapping remains intact.
At this point, the hypervisor has an HTAB with one or more read/write mappings pointing to a buffer it has deallocated. Thus, the kernel no longer owns that buffer and supposedly cannot write to it. However, the kernel still has one or more valid mappings pointing to the buffer and can actually modify its contents. But this is not yet useful since it’s just empty memory.
The exploit then creates a virtual segment and checks to see if the associated HTAB is located in a region spanning the freed buffer’s address. If not, it keeps creating virtual segments until one does. Now, the user has the ability to write directly to this HTAB instead of the hypervisor having exclusive control of it. The exploit writes some HTAB entries that will give it full access to the main segment, which maps all of memory. Once the hypervisor switches to this virtual segment, the attacker now controls all of memory and thus the hypervisor itself. The exploit installs two syscalls that give direct read/write access to any memory address, then returns back to the kernel.
It is quite possible someone will package this attack into a modchip since the glitch, while somewhat narrow, does not need to be very precisely timed. With a microcontroller and a little analog circuitry for the pulse, this could be quite reliable. However, it is more likely that a software bug will be found after reverse-engineering the dumped hypervisor and that is what will be deployed for use by the masses.
Sony appears to have done a great job with the security of the PS3. It all hangs together well, with no obvious weak points. However, the low level access given to guest OS kernels means that any bug in the hypervisor is likely to be accessible to attacker code due to the broad API it offers. One simple fix would be to read back the state of each mapping after changing it. If the write failed for some reason, the hypervisor would see this and halt.
It will be interesting to see how Sony responds with future updates to prevent this kind of attack.
Traduzione:
George Hotz, precedentemente conosciuto come un hacker di iPhone, ha annunciato di aver violato la Playstation 3 e poi sfruttare fornito dettagli. Vari articoli sono stati scritti su questo, ma nessuno di loro sembra aver analizzato il codice vero e proprio. A causa delle varie relazioni in conflitto, ecco alcune analisi di più per aiutare a capire l'exploit.
La PS3, come la Xbox360, dipende da un hypervisor per la tutela della sicurezza. A differenza del 360, la PS3 permette agli utenti di far girare Linux ordinaria, se lo desiderano, ma funziona ancora in fase di gestione da parte della hypervisor. L'hypervisor non permette al kernel Linux di accedere a vari dispositivi, come ad esempio la GPU. Se è stato trovato un modo per compromettere l'hypervisor, l'accesso diretto all'hardware è possibile, e altri codici meno privilegiati potevano essere monitorate e controllate da un aggressore.
Hacking l'hypervisor non è l'unico passo necessario per eseguire i giochi pirata. Ogni partita ha una chiave di cifratura memorizzata in un'area del disco chiamata ROM Mark. Il firmware del disco si legge questa chiave e le forniture per l'hypervisor da utilizzare per decifrare il gioco durante il caricamento. L'hypervisor avrebbe bisogno di essere sovvertito per rivelare questa chiave per ogni gioco. Un altro approccio sarebbe quello di compromettere il firmware del drive Blu-ray o saltare l'estrazione delle chiavi e proprio schiavo del codice di decrittazione, al fine di decifrare ogni partita. Dopo questo, tutte le misure di protezione del software nel gioco dovrebbe essere disabilitato. Non si sa cosa auto-misure di protezione potrebbe essere in agguato sotto la crittografia di un dato gioco. Alcuni autori potrebbero fiducia nella crittografia da soli, altri potrebbero implementare qualcosa di simile SecuROM.
Il codice viene eseguito su hypervisor, sia la CPU principale (PPE) e uno dei suoi sette coprocessori Cell (SPE). Il thread SPE sembra essere lanciato in modalità di isolamento, in cui l'accesso al suo codice privato e la memoria dei dati è bloccata, anche dal hypervisor. Le chiavi hardware radice utilizzata per decifrare l'hypervisor bootloader e quindi sono presenti solo in hardware, possibilmente mediante l'uso di eFUSEs. Ciò potrebbe anche significare che ogni processore Cell ha alcune chiavi univoche, e la decrittografia non dipende da una sola chiave principale a livello mondiale (a differenza di alcuni articoli di tale affermazione vi è un unico, fondamentale radice globale).
George's hack compromette l'hypervisor dopo l'avvio di Linux tramite il OTHEROS "funzionalità". Ha utilizzato l'exploit per aggiungere lettura arbitraria / scrivere le funzioni di accesso di RAM e il dump del hypervisor. L'accesso a lv1 è un primo passo necessario per montare altri attacchi contro il firmware del drive o giochi.
Il suo approccio è intelligente ed è conosciuto come un attacco "glitch". Questo tipo di attacco hardware comporta l'invio di un impulso di tensione con attenzione al momento giusto, al fine di provocare l'hardware a comportarsi male in qualche modo utile. È stato a lungo utilizzato dagli hacker smart card per sbloccare le carte. In genere, gli hacker avrebbero tempo l'impulso per raggiungere una condizione di terminazione del ciclo, causando un ciclo di continuare sempre e dump contenuto della ROM segreto per un bus accessibile. La linea di clock è spesso glitched, ma alcune linee dati sono anche un obiettivo di utile. I tempi di impulso non sempre per essere precisi visto che l'hardware è progettato per tollerare alcune out-of-condizioni specifiche e l'attacco di solito può essere ripetuto molte volte fino a quando non ci riesce.
George collegato un FPGA a una sola riga sulla sua PS3 bus di memoria. Ha programmato il chip con una logica molto semplice: invia un impulso di 40 ns tramite il pin di uscita, quando attivato da un pulsante. Questo può essere fatto con poche righe di Verilog. Mentre la lunghezza dell'impulso è relativamente breve (ma ancora circa 100 cicli di clock di memoria della PS3), l'avvio è molto imprecisa. Tuttavia, ha utilizzato il software per impostare la RAM a dare una maggiore probabilità di successo di quanto non sarebbe primo apparire.
Il suo obiettivo era quello di compromettere la tabella di hash pagina (HTAB) al fine di ottenere in lettura / scrittura di accesso al segmento principale, che tutte le mappe della memoria compresi l'hypervisor. L'exploit è un modulo del kernel Linux che chiama le chiamate di sistema in varie hypervisor si occupano di gestione della memoria. Si assegna, deallocazione, e poi tenta di utilizzare la memoria rilascia come HTAB per un segmento virtuale. Se il glitch desynchronizes con successo l'hypervisor dallo stato attuale della RAM, permetterà il malintenzionato di sovrascrivere il HTAB attiva e quindi controllare l'accesso a qualsiasi area di memoria. Let's scomposizione ancora un po '.
Il primo passo è quello di allocare un buffer. L'exploit poi chiede che l'hypervisor di creare un sacco di duplicati mappature HTAB che punta a questo buffer. Uno di questi mapping può essere utilizzato per leggere o scrivere al buffer, che va bene dato che il kernel possiede. In termini Unix, pensate di questi file come più maniglie per un singolo file temporanei. Qualsiasi file handle può essere chiusa, ma il tempo come un file handle aperto rimane, i dati del file sarà comunque possibile accedere.
Il passo successivo è quello di rilasciare il buffer senza prima rilasciare tutte le mappature ad esso. Questo è ok in quanto l'hypervisor passerà attraverso e distruggere ogni mappatura prima che ritorni. Immediatamente dopo aver chiamato lv1_release_memory (), l'exploit stampa un messaggio per l'utente di premere il pulsante glitch grilletto. Perché ci sono così tante mappature HTAB a questo buffer, l'utente ha una buona probabilità di scatenare il glitch mentre l'hypervisor è una mappatura deallocazione. Il glitch impedisce probabilmente uno o più degli hypervisor di cicli di scrittura da colpire memoria. Scrive queste erano destinati a rilasciare ogni mappatura, ma se dovesse fallire, la mappatura rimane intatto.
A questo punto, l'hypervisor è uno HTAB con uno o più di lettura / scrittura mapping che punta a un buffer che ha rilasciato. Così, il kernel non possiede più che tampone e presumibilmente non si può scrivere su di essa. Tuttavia, il kernel è ancora uno o più mapping valido che punta al buffer e può effettivamente modificare il suo contenuto. Ma questo non è ancora utile, perché non solo la memoria vuota.
L'exploit quindi crea un segmento virtuale e controlla per vedere se il HTAB associate è situata in una regione si estende l'indirizzo del buffer liberato's. In caso contrario, continua a creare segmenti virtuale fino a quando si fa. Ora, l'utente ha la possibilità di scrivere direttamente a questo HTAB l'hypervisor, invece di avere il controllo esclusivo di esso. L'exploit scrive alcune voci HTAB che darà pieno accesso al segmento principale, che tutte le mappe della memoria. Una volta che l'hypervisor passa a questo segmento virtuale, l'attaccante ora controlla tutta la memoria e quindi l'hypervisor stesso. L'exploit installa due chiamate di sistema che danno diretto lettura / scrittura di accesso a qualsiasi indirizzo di memoria, poi ritorna indietro al kernel.
È del tutto possibile che qualcuno pacchetto di questo tipo di attacco in un modchip in quanto il glitch, mentre un po 'stretto, non ha bisogno di essere molto preciso cronometrati. Con un microcontrollore e un po 'i circuiti analogici per il polso, questo potrebbe essere molto affidabile. Tuttavia, è più probabile che un bug del software sarà trovato dopo la reverse-engineering l'hypervisor di dumping e che è ciò che verrà distribuito per l'uso da parte delle masse.
Sony sembra aver fatto un ottimo lavoro con la sicurezza della PS3. Il cerchio si chiude bene, senza evidenti punti deboli. Tuttavia, l'accesso a basso livello al kernel determinato sistema operativo guest significa che qualsiasi errore nella hypervisor è probabile che sia accessibile al codice attacco a causa della vasta API che essa offre. Una soluzione semplice sarebbe quella di rileggere lo stato di ogni mappatura dopo le modifiche. Se la scrittura non riuscito per qualche motivo, l'hypervisor vedrebbe questo e arrestare.
Sarà interessante vedere come Sony risponde con aggiornamenti futuri per prevenire questo tipo di attacco.
Traduzione fatta da Google translate.......
|
