Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Alexander Klink (alexander.klinksit.fraunhofer.de)
Date: Sat Sep 04 2010 - 17:14:35 CDT
Security Advisory for
Adobe Flash Player – user-assisted privacy compromise
Date released: 04.09.2010
Date reported: 08.03.2010
$Revision: 1.1 $
by Security Testlab
Fraunhofer Institute for Secure Information Technology
Product: Flash Player
Vulnerability: privacy problem
Adobe ID: 451
Adobe uses the so-called »Settings Manager« to configure aspects of the Flash
Player application. As the Settings Manager is itself only a flash applet at a
specific URL, it can be spoofed and used to set privacy-related parameters,
such as allowing access to the camera and microphone for an attacker-chosen
The only security measure in place to prevent this for an attacker is that the
Settings Manager has to be retrieved using HTTPS from www.macromedia.com. Thus,
the attacker has to be in a position to control traffic from the user (e.g. a
MiTM situation). Also, user interaction and a moderate amount of social
engineering might be needed to convince the user to accept a certificate for
Attackers with access to a rogue certificate authority (such as
– maybe – your friendly neighbourhood government agency, see
http://files.cloudprivacy.net/ssl-mitm.pdf) may have a slight advantage
The Settings Manager is located at the following URL:
As noted before, the Settings Manager is a flash applet itself, which leads to
the nice note »The Settings Manager that you see above is not an image; it is
the actual Settings Manager.« on the website.
The flash applet is located at
which in turn loads another applet from
(Note the https URL, Flash Player versions earlier than 8 retrieved this
applet via HTTP only)
This applet is now allowed to change the settings for domains which
already have a Local Shared Object (aka »Flash cookie«) set. In particular,
it is possible to set the options for camera and microphone access.
In our proof of concept exploit, this is how the communication
takes place (given that the user has not yet accepted a certificate
for www.macromedia.com). All files on the rogue www.macromedia.com
referenced below have been modified to serve our PoC exploit.
- The user accesses the (rogue) Settings Manager at
(maybe by being forced if the attacker can modify normal HTTP traffic)
If the attacker is lucky, the user ignores the certificate warning
and accepts the certificate. If the attacker is powerful, then there
is no certificate warning
- This page contains an invisible iframe load_evil.html, which redirects
to evil.html on the HTTP server, as settingsmanager.swf has to be
retrieved using HTTP. evil.html in turn contains an embed-tag to load
the modified settingsmanager.swf
- settingsmanager.swf writes a dummy LSO, so that the domain is known
in the next step. After that, it loads settingsmanager2.swf via HTTPS.
- settingsmanager2.swf can now be used to allow the video and camera
to be turned on for www.macromedia.com. Our PoC sets this option for
all domains (just because we can and it was easier to implement).
It then redirects to hidden_record.flv, which uses the camera and
microphone to record the user and sends the data via RTMP to a
* 08.03.2010: Informed Adobe PSIRT about the issue
* 08.03.2010: Adobe PSIRT responds and asks for PoC files
* 10.03.2010: SIT sends PoC files
* 12.03.2010: Adobe PSIRT asks for individual files instead of VMWare image
* 18.03.2010: SIT sends individual PoC files
* 13.04.2010: Conference call regarding status and possible solutions
between SIT and Adobe PSIRT
* 25.05.2010: SIT pings Adobe PSIRT for status update and information
on which solution is chosen
* 17.06.2010: SIT pings Adobe PSIRT again for status update
* 17.06.2010: Adobe PSIRT responds that it is still investigation options
* 06.08.2010: SIT pings Adobe PSIRT for status update and informs them
of intended release on the weekend 3.-5. September
* 06.08.2010: Adobe PSIRT replies that it is looking into the option of
implementing a GUI, »which has proven to be time-consuming«.
No schedule for a fix is yet available.
Adobe currently does not offer a patch for this security issue.
Mitigation is possible though by not allowing the Flash Player to
use the microphone and camera.
Add a line like this:
AVHardwareDisable = 1
to your mms.cfg. For more information about configuring/restricting
Flash Player using mms.cfg, see
Gaffa tape may be effective for blocking camera access as well, but
may be less helpful for blocking microphone access.
- Fraunhofer Institute for Secure Information Technology,
Alexander Klink, Fraunhofer SIT
Forschungsbereich Anwendungs- und Prozesssicherheit
Rheinstr. 75, 64295 Darmstadt, Germany
Telefon: +49 6151 869-229
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/