Web-pages without a defined charset will be rendered with the charset of the parent page when put into an (i)frame. This might allow bypassing XSS filters with for example UTF-7 payload.
Vulnerable Systems:
* Firefox versions 2.0.0.1 and prior
* Internet Explorer 7
* Opera 9
Immune Systems:
* Internet Explorer 6
* Opera 8
While testing Firefox it was discovered that pages not specifying a charset in a HTTP Content-Type header or from within a HTML META tag, inherit the charset of the parent page when they are rendered within an (i)frame, even when both pages are on different domains.
This opens up Firefox to all the UTF-7 XSS vulnerabilities that were reported in the past (google.com, mediawiki, ...) and are usually attributed to only affect Internet Explorer due to its charset autodetection. All an attacker needs to get it working is put the XSS attack into an iframe on a site using UTF-7.
After the initial contact with the Mozilla team Internet Explorer 7 was released which unlike Internet Explorer is also vulnerable to the charset inheritance issue. Hinted by the Mozilla developers it was also discovered that Opera 9 unlike Opera 8 also introduced this vulnerability.
Unfortunately neither Microsoft nor Opera were interested in the vulnerability. Opera did not react at all on our bug report and Microsoft just sent a nonsense mail to us, claiming that we had disclosed this already to the public and that they like getting advance notice. We never heard back from them after that initial email. Not really surprising because it is a similar behavior we previously encountered when dealing with them.
Vendor Status:
Only Mozilla reacted and released Firefox 2.0.0.2 which fixes this issue.
It's strongly recommended to upgrade to Firefox 2.0.0.2 which also fixes several other security vulnerabilities not reported by us and therefore not covered by this advisory.
Disclosure Timeline:
* October 2006 - Notified security@mozilla.org
* February 2007 - Firefox 2.0.0.2 released
* February 2007 - Public Disclosure
