This is the second part of my three part writeup on WebExtensions, Link to part 1. I wanted this part to be the last one but the bugs are taking longer to fix than originally anticipated. Anyway, in this part I will be discussing more complex bugs than in part 1 so I think these will be a bit more interesting.
This bug was one of my first reports on WebExtensions, and the method used here has been fixed but the underlying problem still exists. This bug was pretty simple, I rely on the 'downloads' and 'downloads.open' permissions which enables extensions to download and open files. I noticed that the 'downloads.open()' function worked automatically without user interaction.
But there was a problem, when I attempted to download and open an executable I was given a security error from Windows. This is due to the file being flagged as coming from the internet thus requiring additional user interaction on the OS level to fully execute. This was mitigated by using a '.JAR' file, which is basically a Java based executable which Windows conveniently doesn't create zone identifiers for. So no security prompt is displayed when downloaded and opened from the internet. So I wrote a simple extension that downloaded a JAR file and attempted to execute it, worked!
This was fixed on Firefox by having 'downloads.open()' only work within a valid user action. So technically this still 'works' in that you could trick a victim into clicking something and then you could still execute JAR files.
Also, this attack can work on Google Chrome. The problem with Chrome is that most executable files are not automatically downloaded, there is a small prompt that appears above the executable in the downloads bar that asks if the user wants to keep this potentially dangerous executable. But! the '.EXE' file type is exempt from this rule, I can only imagine this was done so companies can push their legitimate installers without scaring their customers. However, you must still bypass Windows' zone identifier security prompt.
Thanks to the behavior noticed in this bug I was able to use it to get another RCE (CVE-2018-12368) using the infamouse '.SettingContent-ms' file extention (bounty split with founder of said file). This is because Firefox (and Chrome) did not treat this file as executable though it can be used as such.
The original bug report is open, check it out for more details and the original PoC used.
One interesting aspect of browsers is that they usually come with bult-in content handlers. You may have noticed that when you open a PDF file Firefox will allow you to preview it within the browser itself, even without having installed a PDF reader application.
This is due to Firefox running 'PDF.js' which essentially converts PDF into viewable HTML. But did you know that this PDF document is not same-origin with the website its hosted on?
Say you have a window opened 'http://localhost/q.pdf' and you have a reference to that window within 'http://localhost/index.html' you will have no access to the 'q.pdf' reference. This is because despite the addressbar pointing to 'http://localhost/q.pdf' it's actually 'resource://pdf.js/web/'.
This is true for JSON previewer and Feed viewer as well. These content viewers also come with elevated privelege, meaning if you somehow execute code in them you have an elevation of privilege bug.
All I did was notice that a WebExtension did not make this distinction, so I was able to inject Javascript into the PDF viewer/Feed reader. When your extension asks permission for '<all_urls>' you don't have access to 'resource://' URLs, so using the trick here I was able to bypass this restriction.
Now the next step is to actually make use of this elevation of privilege. I could not find any useful functions within PDF, however, not long ago I reported an issue in Feed reader that could lead to RCE with user interaction (I discuss this here). But it was very high in user interaction, so I used the bug here to execute code into the feed reader and lessen the user actions required to achieve the RCE.
Here is the original Youtube video mentioned in my report that shows it in action.
Original report is public here. A lot of other details as well as PoC.
Mozilla's addon domain is considered a semi-privileged page, this is due to it having 'navigator.mozAddonManager' function which could be used to install addons automatically without user consent. So even if your extension has the '<all_urls>' permission you still can't inject javascript into 'addons.mozilla.org'.
so injecting JS into this domain means you have a privilege escalation vulnerability. Which is exactly what I found.
Using the 'webRequestBlocking' permission, I noticed that I could replace the HTML within 'addons.mozilla.org'. But I was hit with a CSP violation when I tried to inject inline script, so it seemed like my efforts were futile until I noticed that the page was including 'https://www.google-analytics.com/analytics.js' without an integrity attribute, so all I did was instead of filtering the HTML within 'addons.mozilla.org', I filtered the Javascript of Google analytics and boom! JS executed and CSP bypassed, with full access to mozAddonManager.
The original bug is now public, I recommend checking it out as it also contains the original PoC extension used.
On Firefox I found that I could still inject Javascript using the devtools functionality within WebExtensions, where you could interact with the Web Inspector. Pretty straightforward in FireFox, original bug is public, again recommend you read it for more details.
However, on Google Chrome this is a much bigger issue, as I found I could inject Javascript into literally all URLs even privileged 'chrome:' pages. However, I was surprised by how Google Security handled the bug report.
I originally reported the issue on 'Dec 17 2017' and it is still not fixed as of writing this. According to some comments in the report, this could be used to perform RCE. And yet this is the last comments in the bug report thread:
Just goes to show that sometimes it's very frustrating to deal with bug reports. This type of behavior is very discouraging to folks like me. I have bugs with Mozilla that are 2 years old but at the very least there seems to be an effort to communicate. But to ignore for months with not even a 'hey im busy can you try to find a fix for this?'. Very shameful from such a big company. Thankfully the sea of infosec is plentiful and full of other spots with much fruitful yields. Forgive my little rant but I needed to voice my dissappointment. Part 3 coming soon and will include some more interesting bugs in WebExtensions. Let me know if you have any questions, my DMs are open (@qab).