lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Sun, 05 Sep 2010 00:14:35 +0200
From: Alexander Klink <alexander.klink@....fraunhofer.de>
To: bugtraq <bugtraq@...urityfocus.com>,
	full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: 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
   http://testlab.sit.fraunhofer.de/

Vendor: Adobe
Product: Flash Player
Website: http://www.adobe.com/products/flashplayer/
Vulnerability: privacy problem
Status: unpatched
Adobe ID: 451

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Summary:

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
domain.

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
www.macromedia.com.

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
here.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Technical details:

The Settings Manager is located at the following URL:

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager.html

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 
http://www.macromedia.com/support/flashplayer/sys/settingsmanager.swf,
which in turn loads another applet from
https://www.macromedia.com/support/flashplayer/sys/settingsmanager2.swf
(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
  https://www.macromedia.com/[...]/settings_manager.html
  (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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Communication:

* 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.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Solution:

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

http://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide/flash_player_admin_guide.pdf

Gaffa tape may be effective for blocking camera access as well, but
may be less helpful for blocking microphone access.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Credits:

- 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
mailto:alexander.klink@....fraunhofer.de
http://www.sit.fraunhofer.de

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ