Langages de programmation sécurisés : le défi de l’adoption

Quel point commun entre le ver Morris (1988) et la faille Heartbleed (2014) ? À tout le moins, celui d’avoir tenu à des problèmes de sécurité de mémoire.

La Maison Blanche y fait référence dans une note technique relative à la réduction de la surface d’attaque dans le cyberespace. Elle y détaille deux approches. D’une part, le développement d’indicateurs « empiriques » pour mesurer la sécurité logicielle. De l’autre, l’adoption des langages de programmation dits sécurisés – c’est-à-dire à gestion automatique de mémoire.

Sur ce dernier point, Washington reprend certaines des statistiques de la NSA, entre autres, avait déjà avancées. Parmi elles, le fait que dans les langages non sécurisées, jusqu’à 70 % des vulnérabilités auxquelles on a attribué une CVE sont liées à des problèmes de mémoire. L’équipe du projet Chromium communique effectivement des données allant en ce sens. Microsoft en a publié de similaires il y a quelques années.

Outre Morris et Heartbleed, la Maison Blanche mentionne le ver SQL Slammer (2003) et l’exploit BLASTPASS (2023). Elle rappelle l’existence de deux grandes catégories de vulnérabilités mémoire : spatiales (accès hors des limites établies) et temporelles (exploitation d’un pointeur après libération, accès inopinément interlacés…).

Méthodes formelles et sécurité basée sur le matériel

Certains environnements, à commencer par l’embarqué, posent des contraintes à l’usage des langages sécurisés. La note technique se concentre sur un secteur en particulier : le spatial. Trois exigences s’y posent : exécution à bas niveau, déterminisme et absence de ramasse-miettes (ou au moins la possibilité de passer outre).

C et C++ sont actuellement les plus utilisés des langages répondant à ces trois exigences. Ni l’un ni l’autre n’entrent dans la catégorie des langages sécurisés. Au contraire de Rust, néanmoins pas encore éprouvé dans le domaine spatial (manque d’outillage, d’acculturation des ingénieurs et de « cas d’usage terrain »).

En attendant cette adoption, la Maison Blanche propose deux techniques complémentaires. En l’occurrence, implémenter la sécurité au niveau hardware et recourir aux méthodes formelles.

Sur le premier point, elle donne l’exemple de l’architecture CHERI (Capability Hardware Enhanced RISC Instructions) et de la technologie MTE (memory-tagging extension). Sur le deuxième, elle cite les analyses statiques avancées, les vérifications de modèles et les tests basés sur les assertions. Des méthodes qu’on peut incorporer dans les outils de développement, au niveau des compilateurs.

Illustration © Timofey_123 – Shutterstock