Implications en matière de sécurité du javascript multithread

Question

Lire cette question sur du javascript multithread, je me demandais s'il y aurait des implications en matière de sécurité en permettant à javascript de générer plusieurs threads.Par exemple, y aurait-il un risque qu'un script malveillant génère à plusieurs reprises thread après thread dans le but de submerger le système d'exploitation ou l'interpréteur et de déclencher l'entrée dans un « pays de comportement indéfini », ou est-ce pratiquement un non-problème ?Existe-t-il d'autres moyens par lesquels une attaque pourrait exploiter une implémentation hypothétique de javascript prenant en charge les threads contre lesquels une implémentation sans thread serait immunisée ?

Mise à jour: Notez que verrouiller un navigateur n'est pas la même chose que créer un exploit de comportement non défini.

Answer 1

Non, plusieurs threads n'ajouteraient pas de problèmes de sécurité supplémentaires dans une implémentation parfaite.Le javascript threadé ajouterait de la complexité à l'interpréteur javascript, ce qui le rendrait plus susceptible d'avoir un bogue exploitable.Mais les threads à eux seuls n’ajouteront aucun problème de sécurité.

Les threads ne sont pas présents dans javascript car "Threads Suck" - en savoir plus auprès du concepteur de langage (http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html)

Answer 2

Eh bien, vous pouvez déjà verrouiller un navigateur et sérieusement ralentir un système avec un JS qui se comporte mal.Les navigateurs éclairés ont mis en place des contrôles pour ce genre de choses et les arrêteront avant qu'ils ne deviennent incontrôlables.

J'aurais tendance à supposer que les discussions seraient traitées de la même manière.

---

Peut-être pourriez-vous alors expliquer ce que vous entendez par « comportement indéfini » ?Un interpréteur qui permettait à un script non fiable de directement contrôler le nombre de threads natifs du système d’exploitation en cours d’exécution serait incroyablement naïf - je ne sais pas comment Gears gère les choses, mais comme l'API est centrée sur Workerpéché WorkerPools, je serais très surpris s'ils ne limitent pas le nombre total de threads natifs utilisés à un nombre très faible.

Answer 3

Eh bien, je pense que le seul exemple majeur de javascript multithread est le chrome de Google (LE LIBÉRERONT-ILS DÉJÀ JEEZ) et si je le comprends, le javascript ne fera qu'un seul processus par onglet, donc à moins qu'il ne commence à générer des onglets (popups), je suppose ce serait un problème nul, mais je pense que Google l'a de toute façon caché, ils exécutent tout le javascript dans un bac à sable.

Answer 4

Encore une fois, nous devons faire une distinction entre 1) la prise en charge multithread dans le langage (ce qui, je ne pense pas, est sérieusement discuté comme quelque chose qui va se produire) et 2) l'utilisation de plusieurs threads dans le moteur/interpréteur JavaScript du navigateur.

Pour le numéro 2, je ne vois pas comment cela peut réellement ajouter d'éventuels problèmes de sécurité au moteur/interprète, à moins qu'il n'y ait des défauts dans la mise en œuvre.