Usb control msg(0x21, 2) Exploit

A null pointer dereference vulnerability exists in the versions of iBoot/iBSS/iBEC found in firmwares 3.1/3.1.1 and 3.1.2 (and presumably everything before) on all iDevices. It was fixed in iBoot-636.66.33, which was included with 3.1.3. iPhone 3GS (new bootrom) and iPod touch (3rd generation) owners who saved their SHSH for the aforementioned firmwares, and iPod touch (2nd generation) (new bootrom) owners could have used it for a tethered jailbreak on 4.0 and 4.1, until Limera1n was released.

Credit (Alphabetical)

• vulnerability: pod2g and westbaer, also discovered independently by gray, also discovered independently by geohot
• exploitation: ius, chronic, pod2g, and posixninja, also geohot
• payload: geohot (blackra1n), chronic and posixninja (greenpois0n)

Vulnerability

pod2g and westbaer discovered, via some reversing + fuzzing, you could overwrite the content of 0x0 thanks to Apple not checking the contents of a register they should have, shown in the disassm below. This can be exploited because MMU maps whatever is running (LLB, iBoot, etc.) to 0x0 so that if an exception vector is triggered, it would jump to the one designed to be used with what is running, versus jumping to what is normally located at 0x0, the bootrom.

All you need to do is send the following (assuming you're using libusb 0.1.x)...

usb_control_msg(iDev, 0x21, 2, 0, 0, 0, 0, 1000);

And thanks to our vulnerability, it will do this:

memcpy(0, LOAD_ADDR, 0x2000);

As you can see, we now have full control over the first 0x2000 bytes of iBoot.

Disassm

// R5: a pointer to a buffer is here if requesttype==0xA1.
//     however, if requesttype==0x21, R5 is undefined.

SRAM:22009ED2                 code_1                                  ; CODE XREF: handle_file_io_control_req+62�j
SRAM:22009ED2 014 36 49                       LDR     R1, =usb_file_loadaddr
SRAM:22009ED4 014 36 4B                       LDR     R3, =usb_file_offset
SRAM:22009ED6 014 28 68                       LDR     R0, [R5]
SRAM:22009ED8 014 09 68                       LDR     R1, [R1]
SRAM:22009EDA 014 1B 68                       LDR     R3, [R3]
SRAM:22009EDC 014 22 1C                       ADDS    R2, R4, #0
SRAM:22009EDE 014 C9 18                       ADDS    R1, R1, R3
SRAM:22009EE0 014 07 F0 94 EF                 BLX     memcpy
SRAM:22009EE4 014 00 2E                       CMP     R6, #0
SRAM:22009EE6 014 53 D0                       BEQ     return
SRAM:22009EE8 014 01 23                       MOVS    R3, #1
SRAM:22009EEA 014 33 60                       STR     R3, [R6]
SRAM:22009EEC 014 50 E0                       B       return

Exploitation

By using a vector rewrite attack, it's possible to replace the address of the irq vector handler (0x38) within a 0x2000 iBoot chunk that we send, with the location of the payload to be executed. Although, since we are hijacking the irq exception vector, you must disable interrupts first. Here is the basic procedure:

• Call enter_critical_task(); disabling interrupts, so that your code can reliably execute.
• Restore 0x38 (irq handler) with the original irq vector address
• DO WHAT YOU WANT AT THIS POINT, YOU MAY NOT USE INTERRUPTS.
• Call exit_critical_task(); re-enabling interrupts.
• Call the irq handler so that the interrupt request that you hijacked can execute.

Roadblocks

If what you send is not 0x2000 bytes, the remainder is filled in with zeroes, which is bad. Due to this, you need to restore the first 0x2000 of iBoot before your payload returns execution to iBoot. Also you must disable interrupts, to prevent iBoot from calling the irq vector while your payload is being executed. Because of this, it rules out the possibility of reading the 0x2000 iBoot chunk needed from NOR, from within iBoot itself, since nor_read(); requires interrupts.

One way to get around the need of sending the 0x2000 iBoot chunk is to hook the image_load(); function in the LLB which is sitting intact in memory. This was successfully done in blackra1n.

The PwnageTool method requires an IPSW to be input in order to create a custom firmware anyway, so the 0x2000 chunk is not an issue. It can just be copied from the iBoot in the IPSW.

Implementation

• blackra1n
• redsn0w