Selon Google, la transition C++ vers Rust prendra plusieurs ann�es. Pour garantir la s�curit� de ces utilisateurs, Google d�cide d'appliquer �galement les principes de conception s�curis�e � sa base de code C++ existante "chaque fois que cela est possible". Google a partag� comment elle a d�ploy� ses principes ainsi que l'impact qu'elle a constat� dans son code C++.Dans le monde de la programmation, les langages C et C++ ont longtemps domin� le d�veloppement de firmware. Cependant, Google a r�cemment fait une d�claration audacieuse : remplacer ces langages par Rust serait non seulement possible, mais aussi relativement facile. Les ing�nieurs d'Android avait notamment affirm� : "Vous verrez � quel point il est facile de renforcer la s�curit� avec des remplacements Rust".
Un responsable de Google avait m�me d�clar� : "Les �quipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++". Ajoutant : "Nous avons not� une r�duction de 50 % de l�effort n�cessaire pour mettre sur pied un service en langage Rust ainsi que pour en assurer la maintenance". Si ces d�clarations lancent un d�bat de la productivit� entre Rust et C++, elles confirment que Google est convaincu de la transition C++ vers Rust.
Cependant, Google a r�cemment annonc� que sa transition vers le Safe Coding et les langages � m�moire s�curis�e "prendra plusieurs ann�es". C'est pourquoi ils appliquent �galement les principes de conception s�curis�e � la base de code C++ existante "dans la mesure du possible". Google pr�cise qu'ils travaillent �galement � "faciliter l'interop�rabilit� avec les langages � m�moire s�curis�e". La migration de C++ vers Safe Buffers r�duit l'�cart entre les langages, "ce qui simplifie l'interop�rabilit� et potentiellement m�me une �ventuelle traduction automatis�e".
En effet, les attaquants exploitent r�guli�rement les vuln�rabilit�s li�es � la s�curit� de la m�moire spatiale, qui se produisent lorsque le code acc�de � une allocation de m�moire en dehors des limites pr�vues, pour compromettre les syst�mes et les donn�es sensibles. Ces vuln�rabilit�s repr�sentent un risque majeur pour la s�curit� des utilisateurs. Sur la base d'une analyse de Google, les vuln�rabilit�s de s�curit� spatiale repr�sentent 40 % des exploits de s�curit� de la m�moire au cours de la derni�re d�cennie :
Voici les d�clarations de Google concernant sa base de code C++ :
Google adopte une approche globale de la s�curit� de la m�moire. L'un des �l�ments cl�s de notre strat�gie est le codage s�curis� et l'utilisation de langages sans risque pour la m�moire dans le nouveau code. Cela entra�ne une diminution exponentielle des vuln�rabilit�s li�es � la s�curit� de la m�moire et am�liore rapidement le niveau de s�curit� global d'une base de code, comme le montre notre article sur l'�volution d'Android vers la s�curit� de la m�moire.
Toutefois, cette transition prendra plusieurs ann�es, le temps d'adapter nos pratiques de d�veloppement et notre infrastructure. Pour garantir la s�curit� de nos milliards d'utilisateurs, nous devons donc aller plus loin : nous appliquons �galement les principes de conception s�curis�e � notre base de code C++ existante chaque fois que cela est possible.
� cette fin, nous nous effor�ons d'introduire la s�curit� de la m�moire spatiale dans le plus grand nombre possible de nos bases de code C++, y compris Chrome et la base de code monolithique qui alimente nos services.
Nous avons commenc� par activer la libc++ renforc�e, qui ajoute la v�rification des limites aux structures de donn�es C++ standard, �liminant ainsi une cat�gorie importante de bogues li�s � la s�curit� spatiale. Bien que le C++ ne devienne pas totalement s�r pour la m�moire, ces am�liorations r�duisent les risques, comme nous l'expliquons plus en d�tail dans notre point de vue sur la s�curit� de la m�moire, ce qui permet d'obtenir des logiciels plus fiables et plus s�rs.
Structures de donn�es dont les limites sont v�rifi�es : Le fondement de la s�curit� spatiale
L'une des principales strat�gies de Google pour am�liorer la s�curit� spatiale en C++ consiste � mettre en place un contr�le des limites pour les structures de donn�es courantes, en commen�ant par renforcer la biblioth�que standard C++ (libc++ de LLVM). La libc++ renforc�e introduit un ensemble de contr�les de s�curit� con�us pour d�tecter les vuln�rabilit�s telles que les acc�s hors limites en production.
Par exemple, la libc++ renforc�e garantit que chaque acc�s � un �l�ment d'un std::vector reste dans les limites qui lui ont �t� attribu�es, en emp�chant les tentatives de lecture ou d'�criture au-del� de la zone de m�moire valide. De m�me, la libc++ renforc�e v�rifie qu'un std::optional n'est pas vide avant d'autoriser l'acc�s, emp�chant ainsi l'acc�s � une m�moire non initialis�e.
Cette approche refl�te ce qui est d�j� une pratique standard dans de nombreux langages de programmation modernes comme Java, Python, Go et Rust. Ils int�grent tous la v�rification des limites par d�faut, reconnaissant son r�le crucial dans la pr�vention des erreurs de m�moire. Le C++ a �t� une exception notable, mais des efforts comme la libc++ renforc�e visent � combler cette lacune. Il convient �galement de noter qu'un renforcement similaire est disponible dans d'autres biblioth�ques standard C++, telles que libstdc++.
Rehausser le niveau de s�curit� de base dans tous les domaines
Apr�s le d�ploiement de la libc++ renforc�e dans Chrome en 2022, Google a d�cid� de la mettre par d�faut dans ses syst�mes de production c�t� serveur. Google affirme que cela a am�lior� la s�curit� de la m�moire spatiale dans tous ses services, y compris les composants essentiels aux performances de produits tels que Search, Gmail, Drive, YouTube et Maps. Bien qu'un tr�s petit nombre de composants restent exclus, Google annonce travailler activement pour r�duire ce nombre et � relever la barre de la s�curit� dans tous les domaines, m�me dans les applications pr�sentant un risque d'exploitation plus faible.
Google commente notamment :
L'impact de ces changements sur les performances a �t� �tonnamment faible, bien que la base de code C++ moderne de Google fasse un usage intensif de libc++. Le renforcement de libc++ a eu un impact moyen de 0,30 % sur les performances de nos services (oui, seulement un tiers de pour cent).
Cela est d� � la fois � la capacit� du compilateur � �liminer les v�rifications redondantes lors de l'optimisation et � la conception efficace de la libc++ renforc�e. Bien qu'une poign�e de chemins de code critiques en termes de performances requi�rent encore l'utilisation cibl�e d'acc�s explicitement non s�curis�s, ces cas sont soigneusement examin�s en termes de s�curit�. Des techniques telles que les optimisations guid�es par le profil ont encore am�lior� les performances, mais m�me sans ces techniques avanc�es, la surcharge de la v�rification des limites reste minime.
Nous surveillons activement l'impact de ces v�rifications sur les performances et nous nous effor�ons de minimiser toute surcharge inutile. Par exemple, nous avons identifi� et corrig� une v�rification inutile, ce qui a conduit � une r�duction de 15 % de la surcharge (de 0,35 % � 0,3 %), et nous avons revers� la correction au projet LLVM pour partager les avantages avec la communaut� C++ au sens large.
Si, dans la plupart des cas, la surcharge de libc++ renforc�e est minime pour les applications individuelles, son d�ploiement � l'�chelle de Google a n�cessit� un engagement substantiel en termes de ressources informatiques. Cet investissement souligne notre volont� d'am�liorer la s�ret� et la s�curit� de nos produits.
Des tests � la production
L'activation de libc++ renforc�e n�cessite un d�ploiement en plusieurs �tapes afin d'�viter de perturber accidentellement les utilisateurs ou de provoquer une panne. Voici les �tapes que Google a suivi :
- Tests : Nous avons activ� pour la premi�re fois la libc++ renforc�e dans nos tests il y a plus d'un an. Cela nous a permis d'identifier et de corriger des centaines de bogues non d�tect�s auparavant dans notre code et nos tests.
- Adaptation : Nous avons laiss� le runtime renforc� "travailler" dans nos environnements de test et de pr�-production, ce qui a donn� aux d�veloppeurs le temps de s'adapter et de r�soudre les nouveaux probl�mes qui sont apparus. Nous avons �galement proc�d� � des �valuations approfondies des performances, en veillant � ce que l'impact sur l'exp�rience de nos utilisateurs soit minimal.
- D�ploiement progressif de la production : Nous avons ensuite d�ploy� la version renforc�e de libc++ en production sur plusieurs mois, en commen�ant par un petit ensemble de services et en l'�tendant progressivement � l'ensemble de notre infrastructure. Nous avons surveill� de pr�s le d�ploiement, en corrigeant rapidement tout plantage ou r�gression des performances.
Pr�vention des exploits : La version renforc�e de libc++ a perturb� un exercice interne de l'�quipe rouge (test d'attaque) et en aurait emp�ch� un autre qui s'est d�roul� avant le renforcement. Selon Google, cela d�montre son efficacit� � contrecarrer les exploits. Les contr�les de s�curit� ont permis de d�couvrir plus de 1 000 bogues et permettraient d'�viter 1 000 � 2 000 nouveaux bogues par an au rythme actuel de d�veloppement du C++.
Am�lioration de la fiabilit� et de la correction : Le processus d'identification et de correction des bogues d�couverts par la libc++ renforc�e a entra�n� une r�duction de 30 % du taux de d�faillance de segmentation de base dans la production, ce qui indique une am�lioration de la fiabilit�...
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.