The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "SHA-1 Image Segment Overflow"
(That isn't SHAtter, that's steaks4uce.) |
m |
||
(9 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
− | '''SHA-1 Image Segment Overflow''' or '''SHAtter''' was an exploit that allowed unsigned code execution from a flaw in the bootrom. It was never used in a public jailbreak |
+ | '''SHA-1 Image Segment Overflow''' or '''SHAtter''' was an exploit that allowed unsigned code execution from a flaw in the [[bootrom]]. It was never used in a public jailbreak because the [[limera1n]] exploit was released first, and more devices were vulnerable to it. SHAtter was patched in the [[S5L8940|A5]] bootrom and therefore, never officially released. |
+ | |||
+ | An implementation of SHAtter is available in [[ipwndfu]]. |
||
== Compatibility == |
== Compatibility == |
||
SHAtter only works with [[S5L8930|A4]] devices: |
SHAtter only works with [[S5L8930|A4]] devices: |
||
− | * [[ |
+ | * [[K48AP|iPad]] |
− | * [[iPhone 4]] ( |
+ | * [[iPhone 4]] (all models) |
− | * [[ |
+ | * [[N81AP|iPod touch (4th generation)]] |
− | * [[ |
+ | * [[K66AP|Apple TV (2nd generation)]] |
== Credit == |
== Credit == |
||
− | * '''vulnerability''': [[User:posixninja|posixninja]] ( |
+ | * '''vulnerability''': [[User:posixninja|posixninja]] ({{date|2010|05}}), also discovered independently by [[User:geohot|geohot]] |
* '''research''': [[User:posixninja|posixninja]], [[User:pod2g|pod2g]], also [[User:MuscleNerd|MuscleNerd]] |
* '''research''': [[User:posixninja|posixninja]], [[User:pod2g|pod2g]], also [[User:MuscleNerd|MuscleNerd]] |
||
* '''exploit''': [[User:Pod2g|pod2g]] |
* '''exploit''': [[User:Pod2g|pod2g]] |
||
==Background Info== |
==Background Info== |
||
− | In |
+ | In {{date|2010|04}} [[User:pod2g|pod2g]] wrote a USB [[wikipedia:Fuzz testing|fuzzer]] (see also: [[fuzzing]]) and tested every single [[USB control messages|USB control message]] possible on his [[N72AP|iPod touch (2nd generation)]]. |
The [[wikipedia:Fuzz testing|fuzzer]] found 2 vulnerabilities: |
The [[wikipedia:Fuzz testing|fuzzer]] found 2 vulnerabilities: |
||
* a heap overflow caused by [[usb_control_msg(0xA1, 1) Exploit|usb_control_msg(0xA1, 1)]] |
* a heap overflow caused by [[usb_control_msg(0xA1, 1) Exploit|usb_control_msg(0xA1, 1)]] |
||
* a way to dump the bootrom using USB descriptors request |
* a way to dump the bootrom using USB descriptors request |
||
− | The team tested these two vulnerabilities on newer devices ([[ |
+ | The team tested these two vulnerabilities on newer devices ([[N88AP|iPhone 3GS]], [[N18AP|iPod touch (3rd generation)]], [[K48AP|iPad]]) and both were already fixed by Apple. |
− | [[User:posixninja|posixninja]] continued |
+ | [[User:posixninja|posixninja]] continued [[wikipedia:Fuzz testing|fuzzing]] on these devices, and found that with a particular sequence of [[USB control messages]], it was possible for the first time to dump the [[wikipedia:.bss|BSS]]+Heap+Stack (on newer devices 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 like the [[0x24000 Segment Overflow]] were done blind!) |
||
− | + | Interestingly, his first attempts to dump the memory resulted in rebooting the device. Research began to figure out why the device would reboot. [[User:posixninja|posixninja]] found the reason and proposed different ideas to exploit this. He also reversed tons of assembly code of the bootrom in this period, giving a support discussion to the team. This took months of work. |
|
+ | 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. |
||
− | Research began to figure out why the device would reboot. [[User:posixninja|posixninja]] found the reason and proposed different ideas to exploit this. He 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]]: [[SHA-1 Image Segment Overflow|SHAtter]] would not have been possible without the clever vulnerability he found and the research he did on the bootrom. |
||
+ | [[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 File Format|IMG3]] control routines was just impossible. It took them weeks to understand why they failed and why they couldn't exploit it this way. |
||
− | 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 [[SHA-1 Image Segment Overflow|SHAtter]]. |
||
+ | They both gave up in {{date|2010|07}} and focused on other subjects. |
||
− | [[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 [[IMG File Format|IMG3]] control routines was just impossible. It took them weeks to understand why they failed and why they couldn't exploit it this way. |
||
− | |||
− | They both gave up in July and focused on other subjects. |
||
== Vulnerability == |
== Vulnerability == |
||
Explanation by [[p0sixninja]] at [[MyGreatFest]]: |
Explanation by [[p0sixninja]] at [[MyGreatFest]]: |
||
− | It tricked the bootrom to think the size of the image uploading was larger then what it actually was. Then when it would try to load the image, it would see that it was wrong. Then it would try to wipe out the entire image with all |
+ | :It tricked the bootrom to think the size of the image uploading was larger then what it actually was. Then when it would try to load the image, it would see that it was wrong. Then it would try to wipe out the entire image with all zeroes and go past it and start wiping out bootrom. |
+ | |||
+ | :Exploitation was done by overwriting SHA-1 registers to zeroes so then when it went to check images it would copy part of image into memory address zero (where the bootrom is). It would take the image uploaded and copy it over top of the bootrom (which turns out to be writable over the data portion). |
||
+ | == References == |
||
− | Exploitation was done by overwriting SHA-1 registers to zeros so then when it went to check images it would copy part of image into memory address zero (where the bootrom is). It would take the image uploaded and copy it over top of the bootrom (which turns out to be writable over the data portion). |
||
+ | * [[p0sixninja]]'s [http://conference.hitb.org/hitbsecconf2013kul/materials/D2T1%20-%20Joshua%20%27p0sixninja%27%20Hill%20-%20SHAttered%20Dreams.pdf HITB 2013 Kuala Lumpur presentation] (SHAttered Dreams - Adventures in BootROM Land; starting at page 51) |
||
[[Category:Bootrom Exploits]] |
[[Category:Bootrom Exploits]] |
Latest revision as of 15:14, 25 October 2021
SHA-1 Image Segment Overflow or SHAtter was an exploit that allowed unsigned code execution from a flaw in the bootrom. It was never used in a public jailbreak because the limera1n exploit was released first, and more devices were vulnerable to it. SHAtter was patched in the A5 bootrom and therefore, never officially released.
An implementation of SHAtter is available in ipwndfu.
Compatibility
SHAtter only works with A4 devices:
- iPad
- iPhone 4 (all models)
- iPod touch (4th generation)
- Apple TV (2nd generation)
Credit
- vulnerability: posixninja (May 2010), also discovered independently by geohot
- research: posixninja, pod2g, also MuscleNerd
- exploit: pod2g
Background Info
In April 2010 pod2g wrote a USB fuzzer (see also: fuzzing) and tested every single USB control message possible on his iPod touch (2nd generation). The fuzzer found 2 vulnerabilities:
- a heap overflow caused by usb_control_msg(0xA1, 1)
- a way to dump the bootrom using USB descriptors request
The team tested these two vulnerabilities on newer devices (iPhone 3GS, iPod touch (3rd generation), iPad) and both were already fixed by Apple.
posixninja continued fuzzing on these devices, and found that with a particular sequence of USB control messages, it was possible for the first time to dump the BSS+Heap+Stack (on newer devices only).
Interestingly, his first attempts to dump the memory resulted in rebooting the device. Research began to figure out why the device would reboot. posixninja found the reason and proposed different ideas to exploit this. He also reversed tons of assembly code of the bootrom in this period, giving a support discussion to the team. This took months of work.
In the meanwhile, 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.
posixninja and 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.
They both gave up in July 2010 and focused on other subjects.
Vulnerability
Explanation by p0sixninja at MyGreatFest:
- It tricked the bootrom to think the size of the image uploading was larger then what it actually was. Then when it would try to load the image, it would see that it was wrong. Then it would try to wipe out the entire image with all zeroes and go past it and start wiping out bootrom.
- Exploitation was done by overwriting SHA-1 registers to zeroes so then when it went to check images it would copy part of image into memory address zero (where the bootrom is). It would take the image uploaded and copy it over top of the bootrom (which turns out to be writable over the data portion).
References
- p0sixninja's HITB 2013 Kuala Lumpur presentation (SHAttered Dreams - Adventures in BootROM Land; starting at page 51)