Chrome, Firefox and Edge Local Files Disclosure

Did you know that you can turn a normal file picker into a folder picker? This is done by adding the attribute 'webkitdirectory' to a given input element of type='file'.

Obviously, the difference being that with the folder picker, you end up loading all the files within a selected folder. An obvious vector for bugs at first glance and so after a bit of messing around I ended up getting a few bugs in all three major browsers.

I will write about each browser seperately since each case is a bit different than the other.

Mozilla Firefox

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.

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.

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.

Microsoft Edge

I reported a similar bug on Edge, the difference was that the default directory was 'My Documents' so I showed that the folderpicker can be used to recieve all the files within a victims documents folder.This has since been fixed.

Google Chrome

Google was the first vendor I contacted regarding this. After initially recieving a SEC-MEDIUM rating, it was later changed to SEC-LOW and ignored for months (~6). It turned out that Chrome would be able to detect this type of bug if anyone would try to use it on a mass scale, as it is logged by browser safety.I'm still confused by this, but I believe what they mean is that they can both detect and block any malicious website that shows sudden high usage of the folder uploader. The same PoC reported to Microsoft works on Chrome as of writing this on 4/13/2017.The worst part is that if the filepicker was defaulted to 'C:\', you would be able to read the entire disk..because the folder picker uploads all files within all sub directories.