[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <CA49DA1D-C661-443A-B176-4CD3C7E3D4F8@sektioneins.de>
Date: Thu, 9 Aug 2007 20:21:41 +0200
From: fukami <fukami@...tioneins.de>
To: full-disclosure <full-disclosure@...ts.grok.org.uk>
Cc: bugtraq@...urityfocus.com, websecurity@...appsec.org,
webappsec@...ts.owasp.org
Subject: Design flaw in AS3 socket handling allows port probing
Design flaw in AS3 socket handling allows port probing
# Summary
Due to a design flaw in ActionScript 3 socket handling, compiled
Flash movies are able to scan for open TCP ports on any host
reachable from the host running the SWF, bypassing the Flash Player
Security Sandbox Model and without the need to rebind DNS.
# Technical background
In AS3 Adobe introduced a new socket-related event called
SecurityErrorEvent. This event is always thrown when a Flash Player
tries to connect to a socket that it is not allowed to connect to by
policy.
The problem with the SecurityErrorEvent is that it's thrown
immediately when a Flash Player tries to connect to a closed TCP
port. If a service is listening on that port the Flash Player writes
the string "<policy-file-request/>" and waits for response from the
service. Nearly no TCP-service will respond to this request.
We can assume the following: When trying to connect to a socket that
the SWF is not allowed to and it doesn't get a SecurityErrorEvent
within 2 seconds the port is most likely open.
A new Flash player instance is used for every probed port because the
Flash Player sends only one policy-file request per player per host
per port.
# Tested platforms
Works on:
* Windows XP SP2: Internet Explorer 6 / Flash Player 9.0.47.0
* Windows XP SP2: Firefox 2.0.0.5 / Flash Player 9.0.47.0
* Windows XP SP2: IE 7.0.5730.11 Flash Player 9.0.47.0
* Ubuntu Edgy: Firefox 2.0.0.5 / Flash Player 9.0.47.0
* Mac OSX 10.4.10: Safari 2.0.4 / Flash Player 9.0.47.0
* Mac OSX 10.4.10: Safari 3.0.2 / Flash Player 9.0.47.0
* Mac OSX 10.4.10: Firefox 2.0.0.6 / Flash Player 9.0.47.0
* Solaris 10 i86: Firefox 2.0.0.3 / Flash Player 9.0.47.0
Doesn't work as expected on:
* Mac OSX 10.4.10: Opera 9.22 / Flash Player 9.0.47.0
# Known limitations
* The Scanner does not work on services that close the TCP-
Connection immediately after they receive Bytes that they don`t
"understand". The port is reported as closed because the
SecurityErrorEvent is thrown when the TCP-Connection is closed.
* The Scanner does not always work as expected when scanning
hosts located in the internet (e.g. google.com). This maybe happens
due to stateful inspection firewalls that close the connections or
long TCP-response times.
# Disclosure Timeline
* 2007/07/23: Problem discovery
* 2007/07/24: PoC available
* 2007/07/25: Vendor notification
* 2007/08/09: Public demonstration at CCCamp
# Possible Fixes
Flash-Player Side (Adobe)
* TOTALLY REMOVE the SecurityErrorEvent (it`s useless, it`s just
harder to find errors with socketservers without the event)
* Remove the SecurityErrorEvent in the Release-Players and keep
it in the debug players
* Make the SecurityErrorEvent behave EXACTLY the same for opened
an closed ports
User Side
* Disable Flash
* Only allow Flash from trusted sites
* Downgrade Player to Version 8
# Links
* Flex 2 Socket: http://livedocs.adobe.com/flex/2/langref/flash/
net/Socket.html
* Flex 2 SecurityErrorEvent: http://livedocs.adobe.com/flex/2/
langref/flash/events/SecurityErrorEvent.html
* Flash Player 9 Security white paper: http://www.adobe.com/go/
fp9_0_security
* Settings Manager: http://www.macromedia.com/support/
documentation/en/flashplayer/help/settings_manager06.html
# Live PoC scanner
* http://scan.flashsec.org/
# Source Code
* http://scan.flashsec.org/classes/Main.as (compile using Adobes
Flex2 SDK)
# Credits
* David Neu david.neu@...il.com Problem-Discovery and PoC
* fukami, SektionEins, http://sektioneins.de/
Powered by blists - more mailing lists