Closed Bug 660851 Opened 13 years ago Closed 13 years ago

Cross-protocol request forgery to initiate calls without user consent

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 167475

People

(Reporter: tadej.vodopivec, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 (.NET CLR 3.5.30729) | version 4 has similar behaviour We have identified unexpected behaviour of several browsers, that could result in security vulnerability under certain conditions on the side of browser's user. The core problem seems that browser proceeds »iframe« HTML tag with »src« attribute referring to some URI schemes, (e.g. »tel:«, obsolete »callto:« or proprietary, but widely supported »skype:«), and submits voice communication program (such as Lync or Skype) the request to call the number or user referred to in scheme specific URI part. Malicious web page creator could include such iframe tag. Three examples and posible impacts: 1. <iframe src=»tel:ATTACKERS_PAYABLE_NUMBER«> where attacker profits from calls to ATTACKERS_PAYABLE_NUMBER 2. <iframe src=»skype:ATTACKERS_COVERT_SKYPE_ID«> where attacker can spy on user (listen to the sounds around user) 3. <iframe src=»tel:VICTIMS_PHONE«> where attacker can initiate distributed denial of service on user's phone number by placing it on frequently visited web page (e.g. exploiting HTML injection vulnerability of the page), making every visitor call the victim. Tested browsers in default configurations ask user for confirmation before they launch voice communication program. Tested voice communication programs in default configuration also ask user for confirmation before dialing. All the tested browsers that manifest the described behaviour give user the choice to easily turn off asking for confirmation. Some tested voice communication programs also give user the choice to easily turn off asking for confirmation. With increased use of »tel:« and similar URI schemes in the context of »a href« HTML tags, we can expect more and more users turning off confirmations wherever possible. Expected behaviour would be to block »iframe« + »tel:« combination, possibly giving the user chance to manually follow the link by clicking it (like Opera Web browser do, or like browsers treat the »img src« + »tel:« ). We cannot figure out a useful case for automated »iframe« + »tel:« combination. Same might be true with other URL schemes like fax or sms if/when implemented. This may also be a problem using JavaScript (e.g. document.location=»tel:+123456789«), however the problems in this context looks like only appear under the Cross-site Scripting condition. some tested combinations: »iframe« + »tel:«, »iframe« + »skype:« + Mozzila Firefox 3.6, 4 (Several MS Win OS) - Asks user for confirmation before launcing application, give user option to permanently accept Skype on Windows: Give user option to permanently accept Reproducible: Always Steps to Reproduce: 1. Have skype installed 2. Open the normal page with href link to e.g. skype: URI (in additional info) 3. click the link to call the contact using Skype 4. As unaware user chose not to be asked for confirmation anymore, both in Firefox and in Skype 5. Open the malicious page (in additional info) Actual Results: Dial occurs automatically from iframe on malicious page Expected Results: Browser should block iframe to automaticaly launch skype. Opera 11.11 hadles it smartly. normal page containing skype: URI <html> href + skype: URI test page<p> <a href="skype:echo123">Call skype echo service</a> </html> malicious page: <html> Iframe + tel: URI test page<p> <iframe src="skype:echo123">No!</iframe> <!---img src doesnt work ---> <!---img src="skype:echo123"---> </html>
Based on the description, this is a dup of bug 167475. As you say, fixing this for <iframes> won't make it impossible for sites to launch helper apps maliciously. We might want to additionally restrict helper apps to "trusted events" (same as for opening popup windows).
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Group: core-security
You need to log in before you can comment on or make changes to this bug.