[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    [FD] Flash: Local SWF files can leak arbitrary local files to the internet
From:       Jann Horn <jann () thejh ! net>
Date:       2015-05-29 21:58:15
Message-ID: 20150529215815.GC14791 () laptop ! thejh ! net
[Download RAW message or body]

Summary:
Flash by design allows local SWF files to read arbitrary local files, but
prevents communication with remote servers. By smuggling data through a timing
side-channel, this can be circumvented, allowing local SWF files to exfiltrate
the contents of arbitrary local files to the internet.

Some more details:
Flash runs normal local SWF files under local-with-file-system restrictions,
which are documented at
<http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000462.html>.
As <http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000452.html>
explains:

    For security purposes, Flash Player places all local SWF files, including
    all legacy local SWF files, in the local-with-file-system sandbox, by
    default (unless some other setting is made). For some legacy SWF files
    (Flash Player 7 and earlier), operations could be affected by enforcing
    restrictions on their access (no outside network access), but this
    provides the most secure default for the users' protection.

    From this sandbox, SWF files may read from files on local file systems or
    UNC network paths (by using the XML.load() method, for example), but they
    may not communicate with the network in any way. This assures the user
    that local data cannot be leaked out to the network or otherwise
    inappropriately shared.

The following was only tested in Google Chrome.

When multiple SWF files are running in the same browser (but in different
frames or tabs), only one of them can run ActionScript code at a time. This
means that a local SWF file can leak information to a network-loaded SWF file
by busylooping, which delays the processing of ExternalInterface calls to the
network-loaded SWF file. (Apparently local HTML files can't interact with
network-loaded SWF files, but the local HTML file can just frame an HTML file
with http origin which in turn loads the SWF file with http origin.)

Chrome prevents downloads of files with a .swf file extension to mitigate
against attacks on the local-with-file-system rules, but that doesn't prevent
an attacker from embedding a file with a different extension as SWF
(<https://code.google.com/p/chromium/issues/detail?id=487475>, WontFix).

I made a PoC that only requires the victim to download one malicious HTML
file and open it locally. Repro steps:

 - go to <https://var.thejh.net/flash_HigNabIalOt6/download.html> in Chrome
 - click the download link
 - open the downloaded file (by clicking on the item in the downloads bar)
 - replace "file:///etc/passwd" with the file URI to some local file
 - press "run"

You should see the contents of the file appear in the red box, one character
every 8 seconds or so. (Yes, it's really slow - I'm sure it'd be possible to
do this much faster, but for a PoC, I think it's enough.) Note that, as this
is a timing attack, less errors occur if the computer is mostly idle.

Sources of the PoC are at <https://var.thejh.net/flash_local_poc.zip>.

This issue was reported to Adobe PSIRT 2015-04-26. They confirmed that they
got the report, but still haven't told me whether they consider this to be a
fixable issue or a wontfix.

So, in other words: Yet another reason why you shouldn't open untrusted HTML
files from the local disk.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[prev in list] [next in list] [prev in thread] [next in thread]