Google appelle à des normes mesurables de sécurité de la mémoire pour les logiciels : les bogues de sécurité de la mémoire « érodent la confiance dans la technologie et coûtent des milliards »

Google appelle à des normes mesurables de sécurité de la mémoire pour les logiciels : les bogues de sécurité de la mémoire « érodent la confiance dans la technologie et coûtent des milliards »

Dans un récent billet de blog, les chercheurs en sécurité de Google préconisent un cadre normalisé pour définir des normes mesurables de sécurité de la mémoire, afin d'orienter les initiatives politiques et d'encourager l'investissement dans des pratiques logicielles plus sûres dans l'ensemble de l'industrie. En mettant l'accent sur la collaboration avec l'industrie et le monde universitaire, Google souligne la nécessité d'adopter des approches adaptables pour obtenir des résultats solides en matière de sécurité de la mémoire, ce qui témoigne d'une attitude proactive dans la construction d'un environnement numérique sûr pour les générations futures.

Cette initiative intervient à un moment où Google admet que la transition vers des langages à mémoire sécurisée comme Rust prendra plusieurs années. L'entreprise décidant d'appliquer, en attendant, des principes de conception sécurisée à sa base de code C++ existante.

Les bogues de sécurité de la mémoire « érodent la confiance dans la technologie et coûtent des milliards », affirme le nouveau billet sur le blog de sécurité de Google, ajoutant que « les approches traditionnelles, telles que l'audit de code, le fuzzing et l'atténuation des exploits, bien qu'utiles, n'ont pas été suffisantes pour endiguer la marée ».

Le billet de blog appelle ainsi à un « cadre commun » pour « définir des critères spécifiques et mesurables permettant d'atteindre différents niveaux d'assurance de la sécurité de la mémoire ». L'espoir est que cela donne aux décideurs politiques « la base technique pour élaborer des initiatives politiques et des incitations efficaces en faveur de la sécurité de la mémoire », conduisant à « un marché dans lequel les vendeurs sont incités à investir dans la sécurité de la mémoire, [...] et les clients seront habilités à reconnaître, exiger et récompenser la sécurité »).


En janvier, les mêmes chercheurs en sécurité de Google ont participé à la rédaction d'un article notant qu'il existe désormais des « technologies de recherche » solides en matière de sécurité de la mémoire qui sont suffisamment matures : des langages sûrs pour la mémoire (y compris des « sous-ensembles de langages plus sûrs comme Safe Buffers pour C++ »), une vérification formelle mathématiquement rigoureuse, la compartimentation des logiciels, et des protections matérielles et logicielles. Les protections matérielles comprennent des éléments tels que l'extension matérielle MTE (Memory Tagging Extension) d'ARM et l'architecture CHERI (Capability Hardware Enhanced RISC Instructions).

Les chercheurs en sécurité de Google appellent aujourd'hui à l'élaboration d'un « plan directeur pour un avenir sans danger pour la mémoire » - bien qu'il soit important de souligner que l'idée est de « définir les résultats souhaités plutôt que de s'enfermer dans des technologies spécifiques ».

Le billet de blog de Google préconise à nouveau un cadre pratique/actionnable qui soit compris de tous, mais qui soutienne différentes approches et permette de s'adapter à des besoins spécifiques tout en permettant une évaluation objective.

Le contenu du billet de blog de Google est présenté ci-desous :

[QUOTE=Google]
Depuis des décennies, les vulnérabilités en matière de sécurité de la mémoire sont au centre de divers incidents de sécurité dans l'industrie, érodant la confiance dans la technologie et coûtant des milliards. Les approches traditionnelles, telles que l'audit de code, le fuzzing et l'atténuation des exploits, bien qu'utiles, n'ont pas suffi à endiguer le problème, tout en entraînant des coûts de plus en plus élevés.

Dans cet article de blog, nous appelons à un changement fondamental : un engagement collectif pour enfin éliminer cette catégorie de vulnérabilités, ancré sur des pratiques de conception sécurisée - non seulement pour nous-mêmes, mais aussi pour les générations à venir.

Le changement que nous appelons de nos vœux est renforcé par un récent article de l'ACM appelant à normaliser la sécurité des mémoires, que nous avons contribué à publier avec des partenaires universitaires et industriels. Il s'agit de reconnaître que l'absence de sécurité de la mémoire n'est plus un problème technique de niche, mais un problème de société, qui a des répercussions sur tout, de la sécurité nationale à la protection de la vie privée.

L'opportunité de la normalisation

Au cours de la dernière décennie, une confluence d'avancées en matière de sécurité de conception a mûri au point de permettre un déploiement pratique et généralisé. Il s'agit notamment de langages à mémoire sécurisée, y compris des langages à haute performance tels que Rust, ainsi que des sous-ensembles de langages plus sûrs tels que Safe Buffers pour C++.

Ces outils s'avèrent déjà efficaces. Dans Android, par exemple, l'adoption croissante de langages à mémoire sécurisée comme Kotlin et Rust dans le nouveau code a entraîné une réduction significative des vulnérabilités.

Pour ce qui est de l'avenir, nous assistons également à des développements passionnants et prometteurs dans le domaine du matériel. Des technologies telles que l'extension matérielle MTE (Memory Tagging Extension) d'ARM et l'architecture CHERI (Capability Hardware Enhanced RISC Instructions) offrent une défense complémentaire, en particulier pour le code existant.

Bien que ces progrès soient encourageants, la sécurité de la mémoire dans l'ensemble de l'industrie du logiciel exige plus que des progrès technologiques individuels : nous devons créer l'environnement et la responsabilité nécessaires à leur adoption généralisée. La normalisation est essentielle à cet égard.

Pour faciliter la normalisation, nous suggérons d'établir un cadre commun pour spécifier et évaluer objectivement les garanties de sécurité de la mémoire ; ce faisant, nous jetterons les bases de la création d'un marché dans lequel les fournisseurs seront incités à investir dans la sécurité de la mémoire. Les clients auront la possibilité de reconnaître, d'exiger et de récompenser la sécurité. Ce cadre fournira aux gouvernements et aux entreprises la clarté nécessaire pour spécifier les exigences en matière de sécurité de la mémoire, ce qui favorisera l'acquisition de systèmes plus sûrs.

Le cadre que nous proposons compléterait les efforts existants en définissant des critères spécifiques et mesurables pour atteindre différents niveaux d'assurance de la sécurité de la mémoire dans l'ensemble de l'industrie. De cette manière, les décideurs politiques disposeront de la base technique nécessaire pour élaborer des initiatives politiques et des mesures incitatives efficaces en faveur de la sécurité de la mémoire.

Un plan d'action pour un avenir sans danger pour la mémoire

Nous savons qu'il existe plusieurs façons de résoudre ce problème et nous investissons dans plusieurs d'entre elles. Il est important de noter que notre vision de la sécurité de la mémoire par la normalisation se concentre sur la définition des résultats souhaités plutôt que sur l'adoption de technologies spécifiques.

Pour traduire cette vision en une norme efficace, nous avons besoin d'un cadre qui permette de :

Favoriser l'innovation et soutenir diverses approches : La norme devrait se concentrer sur les propriétés de sécurité que nous voulons atteindre (par exemple, l'absence de violations de la sécurité spatiale et temporelle) plutôt que d'imposer des détails de mise en œuvre spécifiques. Le cadre doit donc être neutre sur le plan technologique et permettre aux fournisseurs de choisir la meilleure approche pour leurs produits et leurs exigences. Cela encourage l'innovation et permet aux fabricants de logiciels et de matériel d'adopter les meilleures solutions au fur et à mesure qu'elles apparaissent.

Adapter les exigences de sécurité de la mémoire en fonction des besoins : Le cadre devrait établir différents niveaux d'assurance de la sécurité, semblables aux niveaux SLSA, en reconnaissant que des applications différentes ont des besoins de sécurité et des contraintes de coût différents. De même, nous avons probablement besoin d'orientations distinctes pour le développement de nouveaux systèmes et l'amélioration des bases de code existantes. Par exemple, nous n'avons probablement pas besoin que chaque morceau de code soit formellement prouvé. Cela permet d'adapter la sécurité, en garantissant des niveaux appropriés de sécurité de la mémoire pour différents contextes.

Permettre une évaluation objective : Le cadre devrait définir des critères clairs et éventuellement des mesures pour évaluer la sécurité de la mémoire et le respect d'un niveau d'assurance donné. L'objectif serait de comparer objectivement l'assurance de la sécurité de la mémoire de différents composants logiciels ou systèmes, de la même manière que nous évaluons aujourd'hui l'efficacité énergétique. Cela nous permettra de dépasser les affirmations subjectives et d'obtenir des propriétés de sécurité objectives et comparables d'un produit à l'autre.

Être pratique et réalisable : Parallèlement au cadre neutre sur le plan technologique, nous avons besoin de meilleures pratiques pour les technologies existantes. Le cadre devrait fournir des orientations sur la manière d'exploiter efficacement des technologies spécifiques pour respecter les normes. Il s'agit notamment de répondre à des questions telles que : quand et dans quelle mesure un code non sûr est acceptable au sein de systèmes logiciels plus vastes, et des lignes directrices sur la structuration de ces dépendances non sûres pour soutenir le raisonnement compositionnel sur la sécurité.

L'engagement de Google

Chez Google, nous ne nous contentons pas de plaider en faveur de la normalisation et d'un avenir sans danger pour la mémoire, nous travaillons activement à sa construction.

Nous collaborons avec des partenaires industriels et...