From Gnash Project Wiki

Jump to: navigation, search
  • Lenguaje/Language/Langue

|| DE:Deutsch | English | Español | Français | RU:Русский | IT:Italiano | Team ||

This page is for discussion of security-related issues in Gnash


security namespace

ActionScript Class Test Case Status Notes
IURIDereferencer Incomplete. AIR only
RevocationCheckSettings Incomplete. AIR only
SignatureStatus Incomplete. AIR only
SignerTrustSettings Incomplete. AIR only
XMLSignatureValidator Incomplete. AIR only

Types of security


Because it is coded in C++, Gnash avoids some common exploits. Notably, the famous NULL-pointer Flash exploit is not applicable directly to Gnash, because it relies on an unchecked allocation failure. The C++ new operator throws an exception on a failed allocation, so Gnash would abort in this case.

Nevertheless, other parts of that attack - particularly the fact that verification and execution of bytecode are performed independently - may apply to Gnash. Apart from the usual suspects (silly coding errors), Gnash's prime vulnerability lies in the fact that it accesses, parses, and executes byte code. That's what Gnash is for. Failures in checking the integrity of this bytecode can easily lead to illegal memory access, causing crashes, execution of arbitrary code or access to whatever else is in the memory at the time.

  1. Unintentionally malformed SWFs (there are many of these).
  2. Maliciously malformed SWFs: designed to cause a particular consequence when run in Gnash.
  3. SharedObject files: these are generally created by Gnash or another Flash player. Bugs in another player (as well as Gnash) could introduce malformed SharedObject files. Moreover, it is conceivable, though unlikely, that a deliberately malformed SharedObject file could be introduced to a system.
  4. LocalConnection object: this is an AMF object in shared memory, so is presumably vulnerable to anything that affects SharedObject parsing.

In all these cases, Gnash must expect and be able to handle any malformation. The parsing code already includes robustness checking and appears fairly secure after testing with zzuf. The state of AMF checking for malformation is unknown (because I haven't looked at it), though it is presently still possible to introduce assertion failures and even segfaults with malformed .sol files.

Flash also requires the dynamic loading and parsing of XML, JPEG, GIF, PNG, FLV, MP3, MPEG4 (and other media formats), HTML, CSS and text files. This can be done over the network or from the filesystem. Each of these opens another potential window of attack.

Gnash delegates some of this work to well-tested and robust external libraries: libxml2 handles XML, gstreamer or ffmpeg (well, not that robust) handle media formats and libjpeg handles JPEGs. Network connections are currently handled by CURL. This opens Gnash to possible bugs in those libraries, but is in most cases much safer than doing it ourself. Possible problems still lie in Gnash's interfaces with those libraries. How Gnash reacts to malformed network streams has not been tested - testing with corrupt network data identified a large number of bugs in Mozilla Firefox.

Network access

or "SWF movies on the net communicate with hosts I consider evil"

Flash movies running in the browser can make outgoing network connections. This can be used, for example, to compromise a network device inside a company firewall by exploiting its security holes from a flash movie running on an employee's browser.

This problem is inherited from the commercial flash player: their solution in Player 6 was a Security Settings dialogue that, by default, only allows the player to access other pages from the same internet domain.

In Flash Player 8, instead, they disallow all access to the internet from the Flash player by default, however new exploits keep cropping up.

Gnash currently allows you to blacklist hosts that you know are evil, or to whitelist hosts you know are good, by editing a configuration file.

For some examples of some exploits using Flash network access, see

Exploitable bugs in the player

Despite new "security features" and fixes to exploitable bugs in Flash players 6, 7, 8 and 9, version 8 still allowed a malicious Flash movie to hijack your browser, modify your profile on MySpace and so on if you so much as browse a different page on MySpace that contained one. It is therefore very likely that the current Adobe player also has new, improved bugs.

They exploit bugs in the plugin's JavaScript implementation as well as using other techniques to subvert the player/browser combination.

Gnash is likely to have code vulnerabilities due to bugs because its code is large, of varied provenance and cannot easily be audited. Their exploitation by hackers is unlikely due to Gnash's current rarity, and as it is an open-source community project, such bugs are likely to be spotted, reported and fixed before they are exploited.

However, the problem of security flaws in Gnash due to bugs cannot be addressed by a "Security policy panel" which is what this page is all about.

Gnash Extensions

The fileio extension allows reading and writing arbitrary files on the user's filestore.

At present no extensions are compiled in by default; applications requiring them are assumed to be stand-alone application-specific players that know what they are doing.

Something like the security model of PostScript could be used here. Along with a compile time way to not have any file access have a run time flag that when invoked disallows any file access. ghostscript uses -DSAFER


Access to Camera/Microphone

A Flash movie can request access to a user's webcam and microphone and stream what it sees/hears out to the internet.

The commercial player secures has Global and site-specific option panels:

  • Site-specific has "Allow/Deny/Ask/Remember" for each domain you have visited that has tried to access the devices.
  • Global has "Always ask" and "Always deny", which, when pressed, clear all remembered site-specific settings.

This seems suboptimal. Flash movie collections on the same site may have some honest applications and some dishonest, but they are lumped together.

Camera and microphone access are currently unimplemented in Gnash,


Flash movies can store information on your hard disk that can them be picked up later by the same or a different movie. This is like cookies, used to track visitors to a site, only worse.

It's worse than that though, a Flash movie can also upload SharedObjs to the server where they get shared between multiple clients (this is used to support video conferencing and chats).

According to the manual, the commercial player now allows you to disable the storage of Shared Objects for all sites you have not yet visited, and a site-specific dialog to enable/disable it for sites the player knows about. It also has a setting to let you specify how much stuff movies may store (default 100KB total).

SharedObject tutorial: Basics of SharedObjects

See also

Access information on the filesystem

Flash movies might load files from the filesystem (XML.load) and send the XML to a remote host (either by POST or GET methods).

This is currently handled by gnash with a 'locals sandbox' setting. The 'locals sandbox' are the local filesystem subtrees which are allowed to be accessed by the player during run of a movie. From 20 October 2007, users can specify a list of local sandboxes (set/append localSandboxPath) in gnashrc. The directory of the playing movie's base URL is always part of the sandbox for local URLs. Release 0.8.2 will be the first release with this feature.

Known Security Defects

  • Overview: server/parser/sprite_definition.cpp in GNU Gnash (aka GNU Flash Player) 0.7.2 allows remote attackers to execute arbitrary code via a large number of SHOWFRAME elements within a DEFINESPRITE element, which triggers memory corruption and enables the attacker to call free with an arbitrary address, probably resultant from a buffer overflow. [1]. This was fixed for release 0.8.0. [2].