Remember our report on the anonymous hacker demonstrating an Xbox 360 running homebrew earlier this year? As we reported at the time the Chaos Computer Club doesn’t just allow any juvenile shouting tech jargon to speak on its hacker conventions. As it turns out, the hacker was indeed onto something very solid, and thanks to his report the security hole was already patched by Microsoft.
A new report found its way onto the BugTraq mailing list today, detailing the exploit and how and when it got patched. Since the report is full of techie gibberish, we’ll try to explain in layman’s terms how the hack works. The explanation may be slightly off at times, but stick with us as this is meant to explain the exploit to those that haven’t spent the last five years locked up in a cellar hacking operating systems.
How the Xbox 360 is secured
The Xbox 360 is, unlike its predecessor, a well secured machine. Whereas the first Xbox used almost-standard components from Intel and nVidia, every vital chip in the Xbox 360 was designed from the ground up to work only within this specific system and setup, and to secure that specific system. Key to security is the concept of asynchronous encryption: meaning that you use a private key to encrypt the data, which everyone can then decrypt using the widely available public key. The advantage of this concept is that it is impossible to tamper with the data, because you’d need to use the private key to encrypt it again so the system can understand it. In the Xbox 360, the first public key is embedded into the CPU, meaning it can only boot software that was signed using the private key hidden deep within Microsoft’s Redmond vaults. The kernel will then only allow game discs to run that have been signed, and so on. Key to the security is this Chain of Trust, and key to hacking would be to break that chain and inject unsigned code somewhere in the system. Essentially, being able to inject a single line of unsigned code would invalidate the whole chain from that point onwards, and allow you to twist the machine in your control.
As long as that Chain of Trust is not broken, it’s impossible to load unsigned code into the system by common means. That leaves only the option of physical attacks, meaning that you’d have to directly alter the system’s memory using an external source, connected to the memory bus. To stop this type of attack, the Xbox 360 is built around a two-layered hypervisor system. This hypervisor is a small piece of code in the Xbox 360 operating system, which is responsible for constantly checking system integrity by encrypting and hashing bottom-layer code that is to be executed, using key combinations that are freshly generated each time the system boots. Since the code of the hypervisor itself is unwritable during runtime, and the code it guards is signed, this closes the chain of trust once more. Unless you manage to trick the hypervisor into thinking he got data from a valid, signed source, that was modified physically from the outside.
How the exploit breaks into the system
The exploit detailed in the report uses a minor omission in memory address checking in the system. By using existing code validly running under the hypervisor’s supervision, a switch is enforced that lets the CPU switch to “hypervisor real mode” in a valid context, but not verify whether the actual target is located inside the hypervisor’s code. In short, the CPU is tricked into continuing code execution in a random part of memory of the hacker’s choice. Where he can put any code he wants, which isn’t checked by anyone since that code itself is believed to be the hypervisor at that time by the system. With the chain of trust broken, that code could then decide to access the hardware directly and do whatever it wants, even booting a DVD completely without any kind of hypervisor, or using Microsoft’s public keys.
What happened since the exploit was discovered?
A timeline is practically provided in the report:
Oct 31, 2006 - release of 4532 kernel, which is the first version
containing the bug
Nov 16, 2006 - proof of concept completed; unsigned code running in
Nov 30, 2006 - release of 4548 kernel, bug still not fixed
Dec 15, 2006 - first attempt to contact vendor to report bug
Dec 30, 2006 - public demonstration
Jan 03, 2007 - vendor contact established, full details disclosed
Jan 09, 2007 - vendor releases patch
Feb 28, 2007 - full public release
Patch Development Time (In Days): 6
This explains the January 9 dashboard update which was mysteriously dubbed “for performance and stability updates” by Major Nelson. And as I commented myself at the time: “Security and stability fixes are usually kept â€˜under wrapsâ€™ at any software company to prevent hackers trying to target the fixed problems specifically on unpatched machines or to check them for new problems.” How right I was. Anyway, the January dashboard update to kernel 4552 did more than just patch this bug, it’s also rumored to have added a nasty new feature to the system: hard-disabling kernel downgrades. Some hackers had already succeeded before in downgrading the kernel of the system outside Xbox Live’s control, but that loophole is apparently also closed, so once you got a kernel version 4552 or later you can’t go back.
What are the practical consequences of the hack?
In theory: huge. Being able to run unsigned code in hypervisor mode essentially means the whole system is lying bare to exploit. For comparisons, this is not a less guarded backdoor into the bank, this is akin to dropping the vault code on the streets. If kernel downgrades are truly disabled though the exploit is practically useless: new machines ship with a patched kernel, and most machines out there have already been patched by recent games enforcing the update or connecting to Xbox Live. If you still have a box somewhere that was not yet patched into kernel version 4552, you could run unsigned homebrew code on it. It would also mean however you cannot run recent games on it or go online until a workaround is found against games and Live enforcing you to install the latest kernel update.
The Xbox 360’s first severe security hole has been found, but the question now is how effective Microsoft’s patching has been. Have they succeeded in disabling kernel downgrades? If they have, the hack is a nice feat in itself, but with a highly limited userbase because of practical reasons, which probably wouldn’t even warrant homebrew developers to put much effort into the limited community. If the kernel downgrade is still possible, you could get yourself a triple-core hyperthreaded 3.2Ghz powerhouse for 400 bucks, and run anything on there the homebrew folks can pump out, and even play new games or connect to Live once their kernel checks have been found, isolated and neutralized. You wouldn’t be getting Microsoft’s latest updates anymore though.
Hoping that this article clarifies a lot of the confusion left by other sites’ reports, I thank XanTium, Josh and Xanion for submitting a wealth of resources about the bug!