[Full-disclosure] Adobe Flash Player – user-assisted privacy compromise

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

Vendor: Adobe
Product: Flash Player
Website: http://www.adobe.com/products/flashplayer/
Vulnerability: privacy problem
Status: unpatched
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

Technical details:

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
haxeVideo server.


* 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,
Security Testlab

Alexander Klink, Fraunhofer SIT
Forschungsbereich Anwendungs- und Prozesssicherheit
Rheinstr. 75, 64295 Darmstadt, Germany
Telefon: +49 6151 869-229

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Relevant Pages