Code shown to exploit Xbox 360 security

James Delahunty
1 Mar 2007 7:20

An anonymous hacker has discovered a way to hack Microsoft's Xbox 360 console in a way that could have allowed an alternative operating system to run on the hardware. For the hack to work, physical access to the hardware is required to take advantage of a vulnerability in the Xbox 360 hypervisor.
The hypervisor provides encryption and decryption services for the console, and controls access to memory. This ensures that all games and other code run on the console need to be cryptographically signed with Microsoft's private key and run in non-privileged read-only mode.

Flaws in the interaction between unprivileged code and the hypervisor led to the groundwork for the hack. The hacker tipped off Microsoft about the problem and the company quickly produced a patch. Proof of concept code and details were published on BugTraq on Wednesday.

Severity:
Critical (Unsigned Code Execution in Hypervisor Mode)

Vendor:
Microsoft

Systems Affected:
All Xbox 360 systems with a kernel version of 4532 (released Oct 31, 2006) and 4548 (released Nov 30, 2006). Versions prior to 4532 are not affected. Bug was fixed in version 4552 (released Jan 09, 2007 - not a Patch Tuesday).

Overview:
We have discovered a vulnerability in the Xbox 360 hypervisor that allows privilege escalation into hypervisor mode. Together with a method to inject data into non-privileged memory areas, this vulnerability allows an attacker with physical access to an Xbox 360 to run arbitrary code such as alternative operating systems with full privileges and full hardware access.

Technical details:
The Xbox 360 security system is designed around a hypervisor concept. All games and other applications, which must be cryptographically signed with Microsoft's private key, run in non-privileged mode, while only a small
hypervisor runs in privileged ("hypervisor") mode. The hypervisor controls access to memory and provides encryption and decryption services.

The policy implemented in the hypervisor forces all executable code to be read-only and encrypted. Therefore, unprivileged code cannot change executable code. A physical memory attack could modify code; however, code memory is encrypted with a unique per-session key, making meaningful modification of code memory in a broadly distributable fashion difficult. In addition, the stack and heap are always marked as non-executable, and therefore data loaded there can never be jumped to by unprivileged code.

Unprivileged code interacts with the hypervisor via the "sc" ("syscall") instruction, which causes the machine to enter hypervisor mode. The vulnerability is a result of incomplete checking of the parameters passed to the syscall dispatcher, as illustrated below.