It’s unclear whether or not all the numerous people who’ve the Adobe Acrobat browser extension installed actually use it. The extension being installed routinely together with the Adobe Acrobat utility, chances are high that they don’t even learn about it. But safety-smart it doesn’t matter, an extension that’s installed and unused may nonetheless be exploited by malicious actors. So a few months ago I determined to have a look. To my shock, the extension itself did virtually nothing despite having a quite appreciable code dimension. It’s in truth little greater than a approach to current Adobe Document Cloud by way of an extension, all of the person interface being hosted on Adobe’s servers. And that’s the place trouble starts, it’s hard to maintain these privileges restricted to Adobe properties. Companies don’t normally like safety stories mentioning that something bad might occur. While I finally succeeded, this investigation yielded a bunch of lifeless ends which can be interesting on their very own. These have been reported to Adobe, and I’ll define them in this article as properly.
TL;DR: Out of six issues reported, just one is resolved. The principle issue obtained a partial repair, two extra got fixes that didn’t quite handle the issue. Two (admittedly minor) points haven’t been addressed at all within 90 days from what I can inform. Why does identical-origin coverage matter? Why does identical-origin coverage matter? The same-origin policy is probably the most elementary security idea of the online. So even should you go to a malicious web site, that website is restricted to doing mischief inside its own bounds – or exploiting web sites with safety vulnerabilities. What happens if that safety boundary breaks down? Suddenly a malicious web site can impersonate you in direction of other web sites, even if these don’t have any known vulnerabilities. Are you logged into Gmail for instance? A malicious webpage can request your information from Gmail, downloading all of your e mail conversations. And then it might probably ask Gmail to send out emails in your title.
Similarly in case you are logged into Twitter or Facebook, your non-public messages are now not non-public. And your active on-line banking session will allow that malicious web site to test your transaction history (luckily not making any transfers, that usually requires authorization via a second issue). Now you hopefully get an thought why a gap in the same-origin coverage is a critical vulnerability and must be prevented at any cost. Next: Adobe Acrobat extension. As I discussed earlier than, the Adobe Acrobat extension doesn’t really do something by itself. So once you edit a PDF file for example, you aren’t really within the extension – you’re in Adobe’s Document Cloud. You are utilizing a web software. Now that web software has a problem: in order to do one thing with a PDF file, it must entry its data. And with it hosted anywhere on the web, same-origin coverage will get in the way. The standard resolution would be utilizing a proxy: let some Adobe server obtain the PDF file and provide the info to the web utility.
Downside right here: proxy server can’t access PDF files hosted on some firm intranet, and neither PDF files that require the user to be logged in. These can only be accessed via user’s browser. So Adobe went with another answer: let the extension “help” the web application by downloading the PDF knowledge for it. The extension page will try to obtain knowledge from the handle it received via pdfurl parameter and ship it to the frame via window.postMessage(). This can be mostly high quality in the event you navigating to some PDF file have been a mandatory step of the method. ’s manifest. Which means that any webpage is allowed to load chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html and give it no matter worth for pdfurl. Google homepage and intercepting the resulting data would give attackers access to your Google person title for example. Even where CSP is used, its safety is weakened considerably by allowing scripts from a large number of different providers and by utilizing key phrases like ‘unsafe-eval’.
Should demonstrate the issue properly, what may probably go unsuitable? Well, for as soon as Adobe might fix the XSS vulnerability before even taking a look at my proof of idea for this concern. And that’s precisely what they did after all. More than a month after the report they requested me why they couldn’t reproduce the issue. To their defense, they didn’t quit on this challenge though I couldn’t ship a new proof of concept. As of Adobe Acrobat 15.1.3.10, it is partially resolved. I could verify that exploiting it to obtain regular pages no longer works. The half ready for readyReceived and seenPdf variables to be set is new. This is probably meant to address my proof of concept where the message source happened to be an exterior collateral agreement web page. It doesn’t provide any worth past what isValidOrigin() already does nonetheless. This entry can be used to run code within the frame and thus ship messages with the body being the message supply.
