mopdf.com

limited to the factory-installed tools included with it. “Unlock” is an attack on iPhonethat allows it to be used with any wireless service offering the GSM standard, not justAT&T. Without “unlocking” an iPhone, one can only use AT&T’s wireless services.Jailbreaking is the more important of the two because it is the first step to unlocking. Welook at a jailbreak attack in detail and also learn about different unlocking solutions.Due to the commercial success of the iPhone, it makes a good candidate forsecurity analysis. Having close to a million iPhones jailbroken and unlocked within firstsix months of its release, iPhone security has significant financial implications. Withmore than six million users worldwide, any security holes can in iPhone can jeopardizeprivacy of millions of people. Such possibilities solidify the need to analyze iPhonesecurity.3 JAILBREAKINGThe process of gaining root access to the iPhone so that third party tools can beinstalled is called Jailbreaking. Without gaining read-write access to the root system, oneis not able to install third party applications on iPhone. This is found to be very limitingto thousands of iPhone owners who feel restrained from doing whatever they want to dowith a their iPhones—products that they own. Several other fascinating and helpfulgadgets are available for people to use, so why should they be restrained from usingthem? To provide an analogy, it would be like buying a computer and not being allowedto install new programs on it–being forced to use existing programs only. There areseveral websites including www.Installerapps.com that provide interesting gadgets andgames for iPhone. Some of the “most popular games are iSolitaire, iZoo, Tetris,iPhysics, and NOIZ2SA [4].” Beyond providing access to these fun games andinteresting tools, jailbreaking is absolutely crucial for one more reason: unlocking.Without jailbreaking, one cannot install the necessary application to use a wirelessservice other than AT&T (in the U.S.). Close to a million new iPhones were notactivated with AT&T in their first six months [28]. Without jailbreaking, these iPhoneowners would not be able to use the phone part of the iPhone unless they signed acontract with AT&T after switching from their existing GSM wireless service provider.Even for AT&T customers, jailbreaking is still highly desirable for enabling the additionof third party applications to the iPhone.14

3.1 LOOKING FOR IDEASHow can Jailbreak be achieved? iPhone enthusiasts and hackers all around theworld were looking for ideas for achieving this goal. A feasible solution has to bereasonably easy to use and should not take several hours to complete. Hackersinvestigated various techniques for meeting these requirements. They evaluated existinghacks for other phones and devices and searched for similar vulnerabilities in the iPhone.A previous hacker success was using buffer overflow techniques on the SonyPSP. By exploiting a vulnerability in the Tag Image File Format (TIFF) library, libtiff,used for viewing TIFFs, hackers were able to hack PSP to run homebrew games, whichwas normally prohibited [5].Hackers inspected Apple’s MobileSafari web browser to see if it could be targetedfor the same vulnerability. It turned out that for firmware version 1.1.1 of the iPhone,MobileSafari uses a vulnerable version (3.8.1 or earlier) [6] of libtiff [7]. The exploitablevulnerability in libtiff is documented as entry CVE-2006-3459 in CommomVulnerabilities and Exposures, a database tracking information security vulnerabilitiesand exposures [6]. This vulnerability is also documented and tracked in the U.S.National Vulnerability Database [10]. A malicious TIFF file can be created to includethe desired rogue code. When attempting to view the malicious tiff file in MobileSafari(utilizing the vulnerable version of libtiff), the vulnerabilities in libtiff are exploited tocreate a stack buffer overflow, and the malicious code is injected and executed.3.2 STACK BUFFER OVERFLOW AND RETURN-TO-LIBC ATTACKSThe attack we review, which exploits the libtiff vulnerability, uses stack bufferoverflow to inject the code and the return-to-libc technique to execute it. Let us look athow a stack buffer overflow can be created and how a return-to-libc attack works bylooking at an example.Consider the piece of code below [29]:void func (char *passedStr) {char localStr[4];strcpy(localStr, passedStr); // length of passedStr is not checked}15

int main (int argc, char **argv) {func(argv[1]);}Say, our program is called myprog. Now, let us look at a simplified representation of thestack when myprog is executed with “hi” in table 1 below.Parent function’s stackReturn address (4 bytes)char* passedStrhi\0(4 bytes allocated for localStr. String up to 3 characters is a good input)Table 1. Simplified stack representation with proper inputNow, consider the stack when myprog is executed with the string “goodsecurity.”Parent function’s stack“rity” (return address overwritten)“secu” (char* passedStr overwritten)“good” (expected 3 characters \0, got 12)Table 2. Simplified stack representation with corrupting inputAs is clear from the figures above, our program is only capable of handling astring with three characters plus NULL. When a string of more than three characters ispassed, the extra characters cause stack buffer overflow and overwrite other sections ofthe stack. Our function func should have performed a string length check on passedStr toensure that it has three characters or fewer before the NULL. Any piece of code thatmakes a mistake similar to the one in our function func() can cause stack buffer overflow.Matters could get much worse if an attacker finds out about the vulnerability inour function. Instead of passing “security,” a carefully crafted string could be passed inwhich the last four characters, in our example, are replaced by the hex value of a preexisting function in memory [30], say “secu\x12\x34\x56\x78.” In little-endian,16

discussed later, the value would be 0x78563412, which might be the address of afunction, say, system(). When the stack unwinds, instead of execution returning to thecalling function, the pre-existing function indicated by the overwrite bytes will beexecuted (in this case, system()). Moreover, the stack could be overwritten by passingdesired values that could serve as parameters to a pre-existing function [30]. Such anattack is known as the return-to-libc attack. By discovering the address of such afunction, an attacker can use this technique to execute the function to achieve desiredbehavior. Furthermore, by passing a carefully crafted malicious input that exploits astack overflow, an attacker can inject malicious code that gets executed as a chain of callsto such pre-existing functions.3.3 LIBTIFF VULNERABILITYA vulnerability similar to that in the example above is found in libtiff version3.8.1 and earlier: an area of memory is accessed without performing an out-of-boundscheck. The vulnerability is in function TIFFFetchShortPair in the tif dirread.c file [6].That function fetches a pair of bytes or shorts, as the name implies. It should throw anerror if the request is to fetch more than two bytes or shorts. Instead, it fetches anyarbitrary number of bytes requested. This vulnerability was fixed in libtiff version 3.8.2.The source code for both versions of libtiff can be downloaded from the Maptools.orgwebsite [8]. Below are excerpts of that function in libtiff versions 3.8.1 and 3.8.2. First,let us look at the snippet from version 3.8.1:static intTIFFFetchShortPair(TIFF* tif, TIFFDirEntry* dir){switch (dir- tdir type) {case TIFF BYTE:case TIFF SBYTE:{uint8 v[4];return TIFFFetchByteArray(tif, dir, v)&& TIFFSetField(tif, dir- tdir tag, v[0], v[1]);17

}case TIFF SHORT:case TIFF SSHORT:{uint16 v[2];return TIFFFetchShortArray(tif, dir, v)&& TIFFSetField(tif, dir- tdir tag, v[0], v[1]);}default:return 0;}}Now, let us look at the snippet from version 3.8.2, which has the fix for the vulnerability.It is also obvious from the developer’s comments.static intTIFFFetchShortPair(TIFF* tif, TIFFDirEntry* dir){/** Prevent overflowing the v stack arrays below by performing a sanity* check on tdir count, this should never be greater than two.*/if (dir- tdir count 2) {TIFFWarningExt(tif- tif clientdata, tif- tif name,"unexpected count for field \"%s\", %lu, expected 2; ignored",TIFFFieldWithTag(tif, dir- tdir tag)- field name,18

dir- tdir count);return 0;}switch (dir- tdir type) {case TIFF BYTE:case TIFF SBYTE:{uint8 v[4];return TIFFFetchByteArray(tif, dir, v)&& TIFFSetField(tif, dir- tdir tag, v[0], v[1]);}case TIFF SHORT:case TIFF SSHORT:{uint16 v[2];return TIFFFetchShortArray(tif, dir, v)&& TIFFSetField(tif, dir- tdir tag, v[0], v[1]);}default:return 0;}}To take advantage of the vulnerability in the TIFF library, a malicious TIFF filemust be constructed. To accomplish that requires a reasonable working knowledge of theTIFF file format. There are two important objectives to keep in mind while constructing19

a malicious TIFF file: causing buffer overflow and injecting code. The iPhone isconstructed around an ARM processor, thus some knowledge of it is required forsuccessful code injection. Next, we further discuss TIFF and give a brief overview of theARM processor.3.4 TIFFThe TIFF standard is owned and maintained by Adobe. It is tag-based formatused primarily for scanned images [12]. A TIFF file has a header section and descriptivesections at the top of the file with offsets pointing to the actual pixel image data [13].This means that a poorly constructed file may have tags pointing to incorrect offsets oroffsets beyond the end of the file. Such aberrations can also cause buffer flow for poorlywritten programs that read and manipulate tiff images [13]. Some examples of tagsinclude image height, image width, planar configuration, and dot range. Different tagsgive necessary information about the image including color, compression, dimensions,and location of data. Below is an example of a tiff file (in the value column) withdescriptions obtained from Adobe [12].OffsetDescription(hex)hexadecimal notation)Header:0000Byte Order00024200041st IFD offsetIFD:0014Number of Directory ime00A6Next IFD 014000C00FE 0004 00000001 000000000100 0004 00000001 000007D00101 0004 00000001 00000BB80103 0003 00000001 8005 00000106 0003 00000001 0001 00000111 0004 000000BC 000000B60116 0004 00000001 000000100117 0003 000000BC 000003A6011A 0005 00000001 00000696011B 0005 00000001 0000069E0131 0002 0000000E 000006A60132 0002 00000014 000006B60000000020in

Values longer than 4 lution069EYResolution06A6Software06B6DateTimeImage Data:00000700xxxxxxxxxxxxxxxxxxxxxxxxOffset0, Offset1, . Offset187Count0, Count1, . Count1870000012C 000000010000012C 00000001“PageMaker 4.0”“1988:02:18 13:59:59”Compressed data for strip 10Compressed data for strip 179Compressed data for strip 53Compressed data for strip 160 The first two bytes in an Image File Directory (IFD) represent the number ofdirectory entries (14 in the example above) [12]. The IFD then consists of a sequence oftags, 12 bytes each [12]. The first two bytes identify the field, and the next two identifythe field type: short int, long int, byte, or ASCII [12]. The next four bytes specify thenumber of values, and the final four specify the value itself or an offset to the value [12].Below is a sample tiff image taken from [14].21

Figure 6. Example of a TIFF image [14]Since TIFF files are binary, their contents are best viewed in a hex editor.3.5 ARM PROCESSORSince ARM processor ARM1176JZF-S is used in the iPhone, some workingknowledge regarding its architecture and instruction set is required for this study. ARMis a RISC-based processor. Below is a high-level diagram of ARM1176JZF-S obtainedfrom the ARM website [15].The ARM processor can be configured in either little- or big-endian modes toaccess its data [17]. The iPhone runs the ARM processor in little-endian mode. In littleendian mode, if a value in a register is 0x12345678, it appears in memory as 0x78 0x560x34 0x12. This is further illustrated in the figures 8 and 9 below.22

Figure 7. ARM 1176JFZ-S processor [15]Information regarding endian type is important in both writing the exploit and reverseengineering it. Another important piece of information about the ARM architecture isthat the stack is non-executable, unlike in the x86 architecture. The stack growsdownward in the ARM architecture. Detailed documentation of the ARM architectureand instruction set is available at the ARM website [31].23

Figure 8. Big-endian [18]Figure 9. Little-endian [18]3.6 DRE AND NIACIN’S TIFF EXPLOIT JAILBREAKWe now have accumulated the expertise required to understand and partiallyreverse-engineer the libtiff exploit for jailbreaking developed by two teenagers Dre andNiacin. For their project, the process was in fact the reverse of ours; the attack was firstchosen and different required tools were picked up as deemed necessary. The sourcecode for the attack is available on Dre and Niacin’s website [32].24

First, we verify and demonstrate the overflow problem. Though the exploit wascreated for the iPhone, we can demonstrate the overflow on a Windows PC in cygwin tomimic a Unix-like environment. First the exploit source code was downloaded andcompiled. Then, a malicious TIFF was created for version 1.1.1. g itiff exploit.cpp –o a.exe ./a.exe 1.1.1 badDotRange.tiffFigure 10. Malicious TIFF blocked by Norton AntiVirusAn interesting outcome occurred while we attempted to create badDotRange.tiff. The filecreation was blocked by Norton AntiVirus software running on the machine used, as itdetected the file as “Bloodhound.Exploit.166 [33]” as shown in figure 10. Furtherinformation on the vulnerability shows Norton characterizing badDotRange.tiff as aTrojan and a Virus, as shown in figure 11 [33].25

Figure 11. Bloodhound.Exploit.166 trojan [33]Once the work area was put in the list of directories to be excluded by Norton AntiVirus,badDotRange.tiff was finally created; a Hex Editor view of it is presented in Appendix A.1.Next, we demonstrate the malicious TIFF file causing buffer overflow in libtiff.We also show a well formed TIFF file being handled properly by libtiff. For thispurpose, vulnerable libtiff was downloaded, configured, and compiled. libtiff.a wascopied to work area. The program driver.cpp was written to simulate the Safari browserusing libtiff to view a TIFF image. Below is a snippet from that program written in C .int main() {cout "Start!" endl;TIFF* tif TIFFOpen("c:/thesis/tiffExp/t1.tiff", "r");if (tif) {cout "Opened file successfully" endl;26

} else {cout "FAILED to open tiff file" endl;}TIFFClose(tif);cout "End!" endl;return 0;}Next, badDotRange.tiff is copied to t1.tiff and driver.cpp is compiled, linked withlibtiff.a, and run, which results in a segmentation fault. cp badDotRange.tiff t1.tiff g -I /usr/local/include –g driver.cpp –c g driver.o –L. –ltiff –o driver.exe ./driver.exeStart!Segmentation fault core dumped The program execution sequence is described below.TiffOpen() calls TIFFReadDirectory(), which upon encountering the DotRange tag callsTIFFFetchShortPair () as can be seen from the following snippet from tif dirread.c.case TIFFTAG DOTRANGE:(void) TIFFFetchShortPair(tif, dp);break;case TIFFTAG REFERENCEBLACKWHITE: As seen earlier, that function allocates memory for two shorts, but instead receives therequest to fetch 255 of them. Below is the corresponding line in the source code of theattack.27

0x00,0x00,If we change to use little-endian instead, the first two bytes become 0x0150, whichrepresents the DotRange tag [12]. The next two bytes give us the value 0x0003, whichmeans the data type is SHORT [12]. The next four bytes gives us the number of differentvalues for this tag, which is 0x000000ff or 255 in decimal [12]. Finally, the final fourbytes give us 0x00000084 – the offset to the actual values for the tag [12]. By looking atthe TIFF specification [12] and also looking at the code for the corrected version oflibtiff, 3.8.2 [8], we see that the number of different values expected is two for DotRange.As seen in the stack buffer overflow example, attempting to fetch 255 shorts causes astack buffer overflow. In our example, the program overwrites the return value in thestack, changing it to some area in memory that is not accessible, resulting in asegmentation fault. Below, the line in badDotRange.tiff corresponding to the DotRangetag is shown, as it appears in Hex Editor. Though it is insignificant here, note that certaincharacters are not translated properly from a hex editor to the word processor. Thetwelve bytes corresponding to the DotRange tag appear from 0x74 to 0x7f.0000070: 0100 0000 5001 0300 ff00 0000 8400 0000.P.Thus far, we have solved half of the problem of creating an attack by gainingcontrol of the stack. Before we move on to injecting particular code and executing it, wefirst confirm that a well formed TIFF fi

where they can add and remove music and other files via iTunes. Users wanted to install useful and fun third-party applications like widgets and games. Figure 5. An "unlocked" iPhone claimed to be world's first [2] These two limitations placed on iPhone users prompted a series of hack and attack efforts by iPhone enthusiasts and hackers.