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

The problem is that the "cmplwi" instruction compares only the lower 32
bits of the given syscall number; the upper 32 bits are ignored. The
"rldicr" instruction, however, operates on the complete 64 bit register
value.

The syscall handler address is fetched from the syscall handler offset
table at 0x00000000.00001F68+%r0*4. Setting the upper 32 bits of %r0 to
something other than 0 will change the upper 30 bits of the address used
for the syscall handler offset table lookup. We will now explain how the
Xbox 360 security architecture interprets and aliases these upper bits.

When processing the syscall, the processor is running in "hypervisor real
mode", with the MMU switched off. However, when accessing memory
locations with the MSB cleared, an additional offset, the Hypervisor Real
Mode Offset (HRMO), will be applied to all memory addresses.

Due to the Xbox 360 security architecture, main memory is aliased to
different addresses with different properties, in order to conditionally
enable the security features (encryption and hashing). The hypervisor
sets the value of the HRMO special register so that the hypervisor code,
including the syscall jump table, resides in memory which is hashed as
well as encrypted, even when using zero-based addresses.

When accessing memory locations with the most significant address bit
set, the HRMOR setting is not applied. Due to the bug in the "cmplwi"
instruction, setting the corresponding bits in %r0 on syscall entry
allows setting the MSB, thereby overriding the HRMOR setting and tricking
the address lookup of the syscall handler to fetch from memory without
any security features.

With the syscall handler offset table aliased to unencrypted memory, the
syscall handler table can now be modified to direct the hypervisor to
jump to any location in code space that is designated for the hypervisor.
In the proof of concept implementation, a jump to existing hypervisor
code is used with a pre-loaded register value as a trampoline to force
the ultimate execution path to an arbitrary, unencrypted and executable
location in memory.

Proof of Concept Details:
As it is not possible to directly overwrite even non-priviledged code,
existing code needs to be tricked into calling the hypervisor syscall
with the desired register set. This can be done by setting up a stack
frame and forcing a context switch to this stack frame. The bug can be
exploited using the following series of physical memory writes:

Re: [RFC PATCH 0/4] (Take 2): transcendent memory ("tmem") for Linux... can run on top of the hypervisor....steal memory away from Linux.... The difference is that tmem introduces an API to explicitly manage this memory behind a copy interface whereas CMM2 uses hinting and a special fault handler to allow any piece of memory to be marked in this way. ...(Linux-Kernel)