Depuis des années, Google travaille dur pour faire d'Android un système d'exploitation de plus en plus sûr. Les pirates informatiques recherchent toutes les failles qu'ils peuvent exploiter, en utilisant des méthodes banales comme le phishing ou des méthodes plus complexes comme les vulnérabilités de sécurité de la mémoire. Google explique aujourd'hui comment l'approche Safe Coding a permis de réduire considérablement les vulnérabilités de sécurité de la mémoire dans Android ces dernières années.
Google utilise l'approche Safe Coding pour lutter contre les vulnérabilités de sécurité de la mémoire
Les vulnérabilités de sécurité de la mémoire sont celles qui exploitent les bogues liés à la mémoire, tels que les dépassements de tampon, les problèmes de chaîne de format ou les pointeurs suspendus, pour interagir avec la mémoire ou même écrire dessus. Ces types de vulnérabilités sont encore largement présents dans le développement de logiciels. Les développeurs tentent de les attaquer par diverses approches, les atténuations et les détections proactives prédominantes. Cependant, Google est convaincu que le codage sécurisé est l'approche idéale pour minimiser les vulnérabilités de sécurité de la mémoire, comme en témoignent ses résultats avec Android.
L'approche Safe Coding privilégie dès le départ l'utilisation de langages de programmation à mémoire sécurisée. Cependant, il existe des logiciels vieux de plusieurs années qui comportent des millions de lignes de code clés développées dans des langages « non sécurisés en mémoire ». Alors, quelle est la proposition de Google dans ces cas-là ? La réponse réside dans la transition progressive vers des langages à mémoire sécurisée (comme Rust) pour les nouvelles fonctionnalités.
En gros, Google propose que les développeurs commencent à implémenter exclusivement des langages sécurisés en mémoire lors du développement de nouvelles fonctionnalités. En attendant, l'ancien code basé sur des langages non sécurisés restera « inchangé » au-delà de la maintenance classique et des corrections de bugs. Cela se traduit par une interopérabilité sûre, efficace et rentable entre le nouveau et l'ancien code.
Les vulnérabilités de sécurité de la mémoire d'Android ont diminué de 52 % en 6 ans
Selon Google, l'approche Safe Coding a permis de réduire les vulnérabilités de sécurité de la mémoire dans Android de 76 % à 24 % en seulement 6 ans. Cependant, l'idée de conserver un code non sécurisé en mémoire peut sembler contre-intuitive. Après tout, si vous recherchez une sécurité maximale, votre première idée serait de migrer tout votre code vers un langage sécurisé. Bien que cela puisse être vrai, l'approche de Google est logique, et l'entreprise explique pourquoi.
Dans le développement de logiciels, l’efficacité du code et la rentabilité sont essentielles. Certains outils ou systèmes entiers ont nécessité de nombreuses années de développement. Cela implique des millions et des millions de lignes de code fondamentales. Bien qu’une entreprise puisse simplement commencer à réécrire un logiciel à partir de zéro en s’appuyant sur des langages à mémoire sécurisée, l’investissement et les efforts n’en valent probablement pas la peine. La situation pourrait toutefois être différente dans le cas de développements relativement récents, qui n’ont pas beaucoup de temps derrière eux.
Avantages du codage sécurisé et de l'interopérabilité
Google affirme que l’approche Safe Coding, qui repose sur l’interopérabilité du code, est un moyen économique et pratique d’adopter un code sécurisé en mémoire. Cela le rend rentable, car il permet aux entreprises de tirer parti des investissements antérieurs. Le coût est nettement inférieur à celui de la réécriture d’un logiciel à partir de zéro. Il est également efficace car il permet de continuer à développer de nouvelles fonctionnalités tout en intégrant le nouveau code sécurisé.
L’utilisation d’un code intrinsèquement sécurisé en mémoire garantit également des coûts plus faibles à long terme. Les approches précédentes favorisaient un cycle sans fin d’« attaque et de défense » entre développeurs et attaquants. Le recours à des mesures d’atténuation et à des détections proactives nécessitait une action et des investissements continus en réponse aux attaques potentielles. Cependant, le codage sécurisé permet aux développeurs et aux entreprises d’oublier cela et de se concentrer sur la maintenance et l’amélioration des fonctionnalités ou la correction des bugs.
La productivité est également plus élevée grâce à des taux de retour en arrière de code plus faibles. Autrement dit, il y a moins de situations de retour en arrière de code d'urgence en raison de bugs inattendus. Google affirme que Rust offre des taux de retour en arrière de code inférieurs de moitié à ceux de C++. Essentiellement, Safe Coding permet aux entreprises et aux développeurs d'économiser considérablement du temps et de l'argent. Dans l'industrie d'aujourd'hui, qui surveille de près la rentabilité, cela peut être crucial.
Google révèle avoir mis en place l’interopérabilité entre « Rust ↔︎ C++ et Rust ↔︎ Kotlin ». L’entreprise a également contribué financièrement et par le biais d’outils pour alimenter son approche. Par exemple, Google a donné 1 000 000 $ à la Rust Foundation pour accélérer son évolution. Elle a également fourni ses propres outils d’interopérabilité, tels que Crubit et autocxx.

Voici comment l'approche Safe Coding rend les logiciels plus sûrs
Vous vous demandez peut-être encore comment une approche qui maintient le code non sécurisé en mémoire peut conduire à une réduction exponentielle des vulnérabilités de sécurité de la mémoire. Google explique également cela dans son article de blog, de manière très technique, mais je vais essayer de le rendre simple pour tout le monde.
Grâce à des études à grande échelle, USENIX Security et Google lui-même ont découvert un phénomène intriguant. Fondamentalement, la recherche a conclu que la grande majorité des vulnérabilités de mémoire dans les logiciels proviennent du nouveau code. Une part importante provient également du code récemment modifié. Google a également remarqué que la densité des vulnérabilités de sécurité de la mémoire Android diminuait progressivement dans l'ancien code.
Étant donné qu'une grande partie du problème provient du nouveau code, il est logique de se concentrer sur ce sujet, n'est-ce pas ? C'est le raisonnement qui sous-tend la décision de Google d'adopter l'approche Safe Coding. Mais pourquoi davantage de problèmes et de vulnérabilités s'accumulent-ils dans le nouveau code ? C'est parce que chaque langage de programmation a une propriété fondamentale : la maturation.
Bien que la structure fondamentale d’un langage puisse le rendre non sécurisé en mémoire, des mises à jour successives peuvent contribuer à atténuer ce problème. Ainsi, théoriquement, le code non sécurisé utilisé dans les parties plus anciennes du logiciel peut devenir moins vulnérable au fil du temps. En combinant la maturation du code plus ancien avec de nouvelles fonctionnalités développées dans un nouveau code intrinsèquement sécurisé en mémoire, le résultat sera une diminution exponentielle des vulnérabilités de la mémoire.

Google recommande Rust comme langage sécurisé en mémoire
Bien sûr, le portage de parties de code plus anciennes vers des langages comme Rust peut rendre les choses encore plus sûres. Cependant, ce n'est pas toujours possible, du moins pas de manière simple. Il existe des cas où le déplacement d'un seul bloc peut faire s'écrouler tout le château. Google est catégorique sur le fait que Rust est un langage de programmation sûr en termes de mémoire. Donc, si vous souhaitez apprendre la programmation ou un nouveau langage pour être compétitif dans l'industrie d'aujourd'hui, Rust peut être ce que vous recherchez.
Les vulnérabilités de sécurité de la mémoire ne sont pas les seules à exister. Des tiers malveillants continueront de chercher des moyens de contourner les couches de sécurité de tout logiciel. Cependant, la présence de barrières solides dans les « entrailles » du logiciel garantit que les attaquants devront recourir à des méthodes plus banales et facilement neutralisables. Par exemple, vous pouvez éviter d'être victime d'un phishing en faisant simplement preuve de bon sens.
