Accueil > Code > Problématique de sandboxing d’un SWF untrusted chargé dans un SWF trusted

Problématique de sandboxing d’un SWF untrusted chargé dans un SWF trusted

Wouah, quel titre à rallonge. J’ai posté aujourd’hui un petit message sur Mediabox sur une question qui me parait sans réponse (satisfaisante) pour l’instant, et je la mets ici aussi histoire de poster un peu, pasque ces temps-ci, je m’oublie un peu sur ce blog. ^^

Salut les gens,

J’ai une question assez pointue sur la gestion de la sécurité par le Player Flash, avec un peu de bol quelqu’un se sera déjà cogné les dents là dedans. ^^

Voici mon soucis. J’ai deux fichiers SWF executés depuis une installation locale dans un dossier listé dans le répertoire FlashPlayerTrust: le « maître » et un « esclave ». Le « maître » est executé par l’utilisateur. Lors de l’execution de ce dernier, j’aimerais pouvoir charger mon SWF « esclave » et executer du code AS3 placé à l’interieur.

Mais voilà la petite difficulté: le fichier SWF « maître » est une application de confiance (vu que c’est moi qui la code). Les utilisateurs ne peuvent pas la modifier (enfin, ce n’est pas le débat). Elle communique via un Socket avec un serveur distant, et accède à certains fichiers en local ainsi que sur le Web. Jusque là, pas de soucis.

Seulement, mon SWF « esclave », ce n’est pas moi qui le code, c’est des utilisateurs tiers qui n’ont pas toute ma confiance. J’aimerais laisser le code AS dans les SWF « esclave » accéder à certaines parties bien définies d’une API pour permettre la personnalisation de mon application « maître ». Pour cette partie, pas de soucis.

Mais là où ça se corse, c’est que je ne veux pas que les SWF « esclave » produit par des tiers puissent constituer des chevaux de troies. En clair, je ne veux pas qu’ils puissent communiquer avec l’extérieur, via un socket ou des appels à une page http distante.

Il n’y a à ma connaissance pas de moyen de charger un SWF dans une sandbox particulière, je ne peux donc pas bloquer mes SWF « esclave » dans une sandbox Local-with-file.

Je vois deux solutions possibles :

* Ne pas utiliser des SWF avec de l’actionscript. Créer un pseudolangage, et le parser/executer depuis mon SWF « maître ». Ca peut marcher, mais c’est long, pénible et source de bugs, pouvant même ouvrir des failles de sécurité.

* Charger le SWF « esclave » deux fois: une première fois en tant que donnée binaire, pour parser le format de fichier swf et récupérer les tags de bytecode, puis pour parser ce bytecode à la recherche d’appel à l’API Flash bloqués (l’utilisation d’une classe socket, ce genre de trucs). Mais là, le soucis, c’est que si Adobe change une virgule dans son code et modifie d’un poil le bytecode, paf, une faille. Pareil, si un méchant codeur tiers modifie son swf de façon à ce que la signature de sa classe socket soit légèrement différente, mais qu’elle continue à fonctionner pour le player (en admettant que ce soit possible), paf, feinté. Et en plus, c’est long et compliqué à développer.

Donc voilà, ça me parait être un problème insoluble mais sait-on jamais. Avez-vous une idée meilleure que les miennes? ^^

Merci d’avance!

Alors, fidèle lecteur, as-tu une solution? Allez, salut.

Categories: Code Tags:
  1. 31/03/2008 à 19:57 | #1

    J’ai tenté de répondre à ton post ici:
    flash.mediabox.fr/index.p…

    C’est un peu décousu, mais je suis encoe sur le problème. N’hséite pas à m’y faire un feedback si tu as pu avancer dessus :)

  1. Pas encore de trackbacks