Firefox wyciwyg:// cache zone bypass

Risk: Low
Local: No
Remote: Yes
CWE: CWE-200

CVSS Base Score: 6.8/10
Impact Subscore: 6.4/10
Exploitability Subscore: 8.6/10
Exploit range: Remote
Attack complexity: Medium
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: Partial

There is an interesting vulnerability in how Mozilla Firefox handles internal wyciwyg:// pseudo-URIs. These cache-related resource identifiers are meant to be inaccessible by the user - but there are at least three routes to bypass these restrictionss, one of which - HTTP 302 redirect - also improperly employs same-domain policy checks. This combo flaw enables attackers to intercept sensitive data, perform cache poisoning, or carry out URL spoofing (including SSL certs), against sites that scriptually render documents on client side, and hence produce wyciwyg:// resources to begin with. Although not all sites are susceptible to attacks, a good chunk of "Web 2.0", a selection of popular webmails, and several major banks, very much are. A quick demo and a more detailed discussion can be found here: PS. The two remaining routes to bypass wyciwyg:// restrictions (XMLHttpRequest() and view-source: URIs) appear to properly implement same-domain checks (although view-source seems to be nevertheless not functioning as intended). document.write() + XMLHttpRequest to wyciwyg:// URIs can be used by rogue websites to conveniently store and retrieve persistent "markers" on visitor's machine regardless of cookie settings; that's not a disaster, but still not very nice. PS2. Bugzilla entry here - source patch available: Cheers! /mz

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024,


Back to Top