Security-es

From Gnash Project Wiki

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

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

Esta página es para discusiones relacionadas a problemas de seguridad de Gnash

Contents

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

Tipos de seguridad

Vulnerabilidad

Porque es codificado en C++, Gnash evita algunos exploits comunes. Notablemente, el famoso exploit Flash NULL-Pointer no es aplicable directamente a Gnash, porque se basa sobre una falla a una asignación sin verificar. El nuevo operador C++ tira una excepción sobre una asignación fallida, entonces Gnash abortaría en este caso.

No obstante, otras partes de ese ataque - particularmente el hecho de esa verificación y ejecución de un código de byte están realizadas independientemente - puede aplicarse a Gnash. Aparte de los usuales sospechosos (tontos errores de codificación), Gnash's prime vulnerability lies in the fact that it accesses, parses, and executes byte code. Que es para lo que Gnash esta hecho. Fallas en la revisión de la integridad de este byte fácilmente puede llevar a un acceso ilegal de memoria, causando estrellos, ejecución de código arbitrario o acceso a lo que sea que esté en memoria en ese momento.

  1. SWF mal formados sin querer (hay muchos de estos).
  2. SWF mal formados maliciosamente: diseñados para causar una consecuencia particular cuando corre en Gnash.
  3. Archivos SharedObject: estos son generalmente creados por Gnash o otros reproductores Flash. Errores en otros reproductores (como también Gnash) puede introducir archivos SharedObject malformados. Por otra parte, es concebible, considerado improbable, que deliberadamente un archivo SharedObject malformado pueda ser introducido a un sistema.
  4. Objeto LocalConnection: este es un objecto AMF en memoria compartida, por tanto presumiblemente vulnerable a cualquier cosa que afecte el análisis de SharedObject.

En todos estos casos, Gnash debe esperar y ser capaz de manejar cualquier malformación. El análisis del código ya incluye una revisión robusta y parece bastante seguro después de las pruebas con zzuf. El estado de la revisión de AMF para malformaciones es desconocida (porque no lo he mirado), aunque es en la actualidad posible de introducir una falla de aserción e incluso arroja violaciones de segmento con archivos .sol malformados.

Flash también requiere la carga dinámica y parseo de XML, JPEG, GIF, PNG, FLV, MP3, MPEG4 (y otros formatos de medios), HTML, CSS y archivos de textos. Esto puede ser hecho sobre la red o desde el sistema de archivos. Cada uno de estos abre otra ventana de ataques potenciales.

Gnash delega algunos de estos trabajos a librerías externas bien probadas y robustas: libxml2 maneja XML, gstreamer o ffmpeg (bien, no esa robustez) maneja formatos de medios y libjpeg maneja JPEG. Conexiones de red son actualmente manejadas por CURL. Esto abre Gnash a posibles errores en esas librerías, pero es en muchos casos más seguro que hacerlo por nosotros mismos. Posibles problemas aún siguen en las interfaces de Gnash con esas librerías. Como Gnash reacciona a streams de redes mal formadas no ha sido probado - pruebas con redes con tráfico corrupto identifica un largo número de errores en Mozilla Firefox.

Acceso de Red

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

Privacy

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,

SharedObject

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 http://www.epic.org/privacy/cookies/flash.html

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

References