[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnash-commit] gnash/doc/C security.xml
From: |
Rob Savoye |
Subject: |
[Gnash-commit] gnash/doc/C security.xml |
Date: |
Sat, 01 Mar 2008 15:23:02 +0000 |
CVSROOT: /sources/gnash
Module name: gnash
Changes by: Rob Savoye <rsavoye> 08/03/01 15:23:02
Added files:
doc/C : security.xml
Log message:
Missed file.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnash/doc/C/security.xml?cvsroot=gnash&rev=1.1
Patches:
Index: security.xml
===================================================================
RCS file: security.xml
diff -N security.xml
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ security.xml 1 Mar 2008 15:23:01 -0000 1.1
@@ -0,0 +1,108 @@
+ <sect1 id="spec-security">
+ <title>Security</title>
+
+ <para>
+ Many Flash implementations contain potential security exploits that
+ could compromise a viewer's system. With &app;, an end-user has the
+ ability to see "what's going on" — what types of data the
+ application accesses, where it is found, and how it is used. Many
+ known Flash exploits are included in the &app; test suite that is
+ used to check whether a release is ready for the public. The &app;
+ developers are also in the process of a security review, developing a
+ security layer that will protect an end-user, no matter what operating
+ system they use.
+ </para>
+
+ <para>
+ One early security feature is the blacklist/whitelist. Flash movies
+ running in a browser can make outgoing network connections. This can
+ be used, for example, to compromise a network device inside a
+ company firewall via a Flash movie running on an employee's
+ browser. &app; allows you to blacklist hosts that you know are
+ insecure, or to whitelist hosts you know are secure, by editing a
+ configuration file.
+ </para>
+
+ <sect2 id="lso">
+ <title>Local Shared Objects</title>
+
+ <para>
+ SWF movies support a form of persistant storage called Local
+ Shared Objects. These are stored in the subdirectories of one's
+ <emphasis>~/.macromedia</emphasis> configuration. These files
+ are comonly called "Flash Cookies", as they don't get
+ deleted when the SWF movie that created or writes data to them
+ stops executing. These files often store things like game
+ scores.
+ </para>
+
+ <para>
+ Till recently, what was contained in these files wasn't widely
+ known. There are several LSO file utilities floating around on
+ the Web. Gnash has it's own <emphasis>soldumper</emphasis>
+ program that lets one find and dump the contents of these
+ files. As of yet, I haven't discovered any nasty privacy issues
+ yet, but as Gnash's SharedObject support is new, I may have just
+ been lucky.
+ </para>
+
+ <para>
+ An LSO file uses a <emphasis>.sol</emphasis>suffix, and is
+ stored in binary, big endian format. While one can look at the
+ data in any binary editor or hex dumper, it's easier to use
+ soldumper, which knows how to decode all the objects. The data
+ is stored in AMF format, a simple data interhange formats used
+ in several other places in SWF.
+ </para>
+
+ <para>
+ The one security setting Gnash supports is the
+ <emphasis>SOLReadOnly</emphasis> setting for your $HOME/.gnashrc
+ file. This makes Gnash never write to a .sol file, it only reads
+ them. You can also set <emphasis>SOLSafeDir</emphasis> to a safe
+ subdirectory,or even remove it later, although most people
+ willwant to set this path to the default one created bythe other
+ SWF player.
+ </para>
+
+ </sect2>
+
+ <sect2 id="lc">
+ <title>Local Connections</title>
+
+ <para>
+ SWF movies support a form of data interchange between running
+ SWF movies called LocalConnection. This uses a shared memory
+ segment to exchange AMF objects. While the specification claim
+ an application has to register as a Listener, it turns out in
+ reality this isn't required. Even YouTube violates this
+ requirement. While one would think that data written to this
+ memory segment would go away when the SWF movies are done
+ playing, but they are persistant, and on some systems, the data
+ even survives a reboot. Thank you Solaris...
+ </para>
+
+ <para>
+ The Gnash utility <emphasis>dumpshm</emphasis> can be used to do
+ several things with these shared memory segments. This utility
+ can find the shared memory segment left by using other SWF
+ players to see what has been left. it can then dump the contents
+ of the shared mempory segment either by decoding the AMF objects
+ and printing the values, or by dumping the raw file to disk
+ where you can analysze it with any other program you wish. If
+ you run dumpshm repeatedly, you can even do a crude packet
+ sniffing between two SWF movies playing.
+ </para>
+
+ <para>
+ The only current security related option for this is
+ <emphasis>LocalConnection</emphasis>. This just disables all
+ communication with other SWF movies. Work is in progress on
+ adding a tracing ability to Gnash.
+ </para>
+
+ </sect2>
+
+</sect1>
+
+</chapter>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnash-commit] gnash/doc/C security.xml,
Rob Savoye <=