The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Fuzzing"
(Initial creation, please edit mercelessly) |
(No difference)
|
Revision as of 05:57, 27 October 2013
Fuzzing
The idea behind fuzzing is that a sufficiently complex program (specifically, one designed to be able to accept an infinite amount of different inputs, such as packets or files) cannot possibly know how to parse and handle an infinite amount of different inputs, throwing errors when that input is invalid. Fuzzing is a technique that consists of repeatedly and intentionally providing a program with invalid (and in some cases, random) input in an attempt to cause the program to behave erratically. Erratic behaviors include, but are not limited to: crashing the program, halting it, leaking memory, failing error handling, bypassing input sanitation checks, etc. These behaviors are desired because they occasionally hint at deeper, underlying vulnerabilities can potentially be exploitable. The two most common targets of fuzzing are files and file formats, and network protocols; any input can be fuzzed, however.
For a detailed description on fuzzing, you should probably look elsewhere. This page deals with fuzzing in its relation to iOS. Fuzzing has been used in the jailbreak scene on several occasions to find bugs. Two notable occasions include SHAtter by the Chronic Dev Team, where DFU mode was fuzzed on non-standard pins using a special cable, and Saffron by Comex, where PDFs were fuzzed leading to the discovery of a vulnerability present in the handling of true-type fonts.
Fuzzing MobileSafari
Fuzzing iOS applications, MobileSafari specifically, was covered in chapter 6 of the iOS Hacker's Handbook. MobileSafari has specific interest as an injection vector because it handles so many different filetypes. It's easily the largest remote attack surface on the iOS platform. From p0sixninja: "MobileSafari is special, it's the only process that is allowed JIT permissions. It can execute dynamically generated bytecode." Given these facts on top of how many public exploits there are in webkit, the engine behind MobileSafari, it's surprising how few jailbreaks take advantage of exploits in MobileSafari. The "JailbreakMe" series of jailbreaks are the primary way MobileSafari has been historically exploited. This has a lot to do with the complicated exploit chain necessary to go from an exploit in MobileSafari to a kernel exploit. Still, MobileSafari exploits are more valuable and higher risk because they can be deployed remotely. For this reason, the fuzzing of MobileSafari has remained relevant despite the relative lack of public releases of end-to-end jailbreaks that utilize them. Tools have been developed to fuzz files directly on a jailbroken iOS device. The source for a python fuzzer is in chapter 6 of the iOS Hacker's Handbook. Zzuf was ported to iOS by Comex. Multiple solutions have been implemented for the automatic injection of fuzzed files into MobileSafari, most utilizing an instance of a local server on the device (such as lighttpd) and a tweak that causes MobileSafari to refresh, loading a new file, each time a darwin notification is received. Using these and other methods, MobileSafari has been fuzzed with some success.
Fuzzing DFU Mode
Someone who knows more about how this was done should complete this section. From what I understand, DFU mode was fuzzed on non-standard pins through almost every command that can be fed to DFU by p0sixninja & the Chronic Dev team. Crashes were found that led to the discovery of a vulnerability which was later exploited by pod2g and p0sixninja. Presumably, fuzzing is how several DFU bugs have been discovered.