Sécurité de l’open source : Mozilla parie sur WebAssembly

Sécuriser la réutilisation de code tiers dans des projets de développement ? Il y a les « nanoprocessus » pour ça.

Intel, Red Hat, Mozilla et Fastly entendent mettre ce concept en œuvre sous l’égide de la Bytecode Alliance, dont ils viennent d’annoncer la constitution.

Leur support de travail se nomme WebAssembly.

Il s’agit d’un langage de bas niveau conçu à l’origine comme un complément à JavaScript. Son format binaire est lisible par l’homme.
Sur le web, il fournit un moyen d’exécuter du code écrit dans divers langages (C, C++, Rust) à une vitesse proche du natif.

L’une de ses spécificités réside dans la prise en charge de l’exécution en bac à sable (sandbox).

Isoler pour maîtriser

C’est cette particularité que la Bytecode Alliance compte mettre à profit pour étendre WebAssembly au-delà des navigateurs.

En toile de fond, un constat : en moyenne, 80 % du code utilisé dans les projets de développement est issu de sources tierces.
Il en résulte d’autant plus de risques de sécurité. Mozilla et consorts les illustrent par l’exemple de Zip Slip. La faille a touché de nombreux écosystèmes dont JavaScript, Ruby, .NET et Go.

Solution envisagée : adapter WebAssembly pour proposer une protection équivalente à celle que les systèmes d’exploitation garantissent à travers l’isolation des processus. Mais avec une empreinte mémoire optimisée.

Cette vision se résume dans la notion de « nanoprocessus », chacun d’entre eux pouvant contenir une ou plusieurs instances de modules WebAssembly.

Du datacenter à la périphérie

Par défaut, tous ces modules résident dans une sandbox. Ils n’accèdent aux API et aux appels système que si on les y autorise explicitement.
Ils n’ont pas ailleurs accès qu’à la zone mémoire qui leur est assignée, sans reposer sur une ressource partagée.

Pour assurer la communication entre modules, la Bytecode Alliance développe diverses interfaces. Objectif : permettre la copie de données sans les sérialiser et les désérialiser. Y compris pour deux modules compilés dans différents langages.

Une autre interface est développée afin d’intégrer un système de permissions aux API et appels systèmes. Un mécanisme de virtualisation est par ailleurs à l’étude pour faciliter la communication entre les modules et leurs dépendances.

La Bytecode Alliance a pris sous son aile une première sélection de projets. Parmi eux :

• Wasmtime
  Ce runtime indépendant peut servir de CLI ou être embarqué dans d’autres systèmes. Compatible x86_64, il doit servir de base à des runtimes plus spécifiques.
• Lucet
  C’est l’un de ces runtimes « spécifiques ». Porté par Fastly, il est axé sur la réduction de la latence (notamment à travers la compilation anticipée (AOT). Ce qui le destine en particulier aux CDN et à l’informatique en périphérie (edge).
• WARM (WebAssembly Micro-Runtime)
  Un runtime destiné au monde de l’embarqué (Arm, MIPS, x86 32 et 64 bits). Il utilise un interpréteur pour limiter l’empreinte mémoire.

La Bytecode Alliance promeut aussi des outils destinés à entrer dans la composition de runtimes. Par exemple le générateur de code Cranelift, qui parallélise la compilation au niveau des fonctions.

Photo d’illustration © isaak55 – Shutterstock.com