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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.