Maddin, Donnerstag, 4. Januar 2007, 11:19 Browser add-on security (Part II): XSSed by Acrobat Reader At the 23C3 Stefano Di Paola and Giorgio Fedon from OWASP Italy gave a talk on various methods to undermine the security of AJAX applications. Part of their presentation was the disclosure of an universal XSS (UXSS) problem with Adobe Acrobat reader in connection with Firefox: Acrobat reader supports "open parameter", a method to pass additional display information to a pdf that is served from a web server (e.g. to autofill some forms). Some of these parameters accept general URLs as input. In such a case the reader plug-in request the given URL and uses the received data to determine how the pdf should be displayed:
This results in creating a XSS problem in every single web application that host at least one pdf-file and that is accessed by a Firefox/Acrobat Reader combination (so approx. 10% of all browsers). Autsch.
Adobe patched the problem with Acrobat Reader version 8.0.
Lessons learned:
This issue is an excellent example how third party add-ons can undermine the security of otherwise well audited web applications (like my finding on Greasemonkey scripts with the difference that the install-base of Acrobat Reader is a lot (!) bigger that the number of people using Greasemonkey).
Therefore, one advice to all developer and owner of web applications: All content that you serve from your application that is interpreted by a third party browser add-on may be subject to client-side XSS problems. As the cause for these problems lies within the browser add-on, there is few that can be done on the server side. For this reason all static non-html content (like pdfs, swfs, ...) should be served from a separate subdomain (e.g. pdf.site.com). If a client-side UXSS exists, only this subdomain is affected and the main application (hosted on www.site.com) is still safe.
An interesting side note: When i talked to Stefano and Giorgio at the 23C3 congress, it seemed as if they were under the impression that this was only a minor discovery compared to the memory corruption vulnerability they found in Acrobat reader. While this is somewhat true, their other discovery could lead to complete owning of the victim's computer, a UXSS in that magnitude simply was not discovered in the wild before. Cudos guys.
Update:It turned out that by accessing a pdf file from the local harddisc via the file:// protocol specifier, the attacker can also execute JavaScript inn the security context of the local computer, thus allowing the JavaScript access to private resources like e.g., local files.
If I correctly understand the same-origin policy as described here: www.mozilla.org
then one should be aware of the following:
Serving all PDF content from pdf.site.com prevents XSS attacks on www.site.com. However, it does not prevent XSS attacks on site.com (without the www).
So, for this defense to work, one should not actually use a "subdomain" of the main site. Instead one should use a "sibling domain" (or "cousin domain", so to speak) of the main site.
I once thought so too... But, to do so the malicious JavaScript would have to change its domain by setting the document.domain property.
The way the same origin is implemented in modern browsers in respect to this capability of JavaScript is, that the browser treats the domain of content served from site.com and a script that did set its domain value to site.com after being served from subdomain.site.com differently. If two scripts from different subdomains want to communicate, both have to set actively their document.domain value to omit the subdomain prefix. Microsoft did document this behaviour here (I do not know, if such documentation exists for Mozilla based browsers).
I learned this while I was investigation DNS pinning. Breaking pinning would be a lot easier, if this restriction did not exist.
