Rust est le langage de programmation le plus apprécié pour la cinquième fois. Est-il notre nouveau sauveur en matière de sécurité ?

Ces dernières années, il semble que les ingénieurs logiciels du monde entier ne puissent plus se passer de Rust pour programmer. Ce langage de programmation système relativement récent, créé par Mozilla, a conquis le cœur de la communauté Stack Overflow. Et comme il s'agit d'un groupe peu enclin à se laisser berner, lorsqu'ils élisent un langage « langage de programmation le plus apprécié » cinq années de suite, il est temps pour nous tous d'y prêter attention.

Le langage de programmation Rust intègre des éléments connus et fonctionnels issus de langages couramment utilisés, tout en adoptant une philosophie différente qui élimine la complexité pour privilégier la performance et la sécurité. La courbe d'apprentissage est réelle, et de nombreux développeurs n'ont pas encore l'occasion de l'utiliser beaucoup - seuls 5,1 % des personnes interrogées sur Stack Overflow l'utilisaient couramment. Quoi qu'il en soit, on ne peut nier qu'il s'agit d'un langage passionnant, doté d'une puissance de sécurité bien supérieure à celle de ses prédécesseurs, comme le C et le C++. Une adoption massive nécessitera des changements, tant comportementaux que technologiques... mais pour l'instant, il continue de captiver l'attention des développeurs sur le plan théorique.

... mais attendez, nous devons mettre en lumière un point supplémentaire : il est important de noter que Rust est un langage de programmation qui donne la priorité à la sécurité mémoire et à l'éradication des failles de sécurité liées aux problèmes courants de gestion de la mémoire. Ce sont des enjeux majeurs (qui causent sans aucun doute bien des migraines aux équipes de sécurité applicative), mais ce ne sont pas les seuls défis de codage sécurisé auxquels nous sommes confrontés.

Que prévient exactement Rust ? Et où restons-nous exposés dans le paysage de la sécurité ? Analysons cette nouvelle licorne de la programmation :

La nouvelle frontière de la programmation système moderne et sécurisée en mémoire

L'équipe de recherche et développement de Mozilla a travaillé sur des projets incroyables, et investir dans la programmation Rust en tant que pionnier de l'open source ne fait pas exception. Leur vidéo de présentation donne un aperçu de leur philosophie, avec un thème clé très clair : l'approche actuelle de la sécurité logicielle est défaillante, et Rust est conçu pour résoudre une grande partie de ce problème.

Cela semble trop simpliste, surtout si l'on considère les énormes violations de données auxquelles nous sommes confrontés un jour sur deux, comme la récente bévue effroyable signalée par EasyJet. Des millions d'enregistrements de données sont fréquemment compromis, presque toujours à cause d'une vulnérabilité d'application web, d'une mauvaise configuration de sécurité, ou d'une attaque par hameçonnage, et des langages comme le C++ existent depuis des décennies. Cependant, cela n'a pas suffi aux développeurs pour les maîtriser au point de mettre en œuvre les meilleures pratiques de codage sécurisé. Pourquoi Rust serait-il différent ? De nouveaux langages ont déjà vu le jour, et ils n'ont pas pour autant trouvé le moyen d'éradiquer les vulnérabilités courantes ou de garantir que tout code écrit est magiquement parfait une fois compilé.

Aussi simple que soit le concept, ce sont parfois les réponses simples qui permettent de résoudre des questions complexes. Rust est, à tous égards, une révolution dans la programmation système sécurisée en mémoire qui tient ses promesses à bien des égards... et il sauve certainement la mise aux développeurs susceptibles d'introduire des erreurs pouvant causer de gros problèmes si elles ne sont pas détectées. Java, C, C++, et même des langages plus récents comme Kotlin et Golang, restent assez impitoyables pour le développeur peu sensibilisé à la sécurité. Avec eux, il n'y a pas d'avertissements intégrés, aucun signe particulier indiquant que la fonctionnalité géniale qui vient d'être compilée cache un problème de sécurité sous le capot.

Alors, creusons un peu plus :

Qu'est-ce qui rend Rust si sécurisé ?

En règle générale, l'objectif principal d'un développeur est de créer des fonctionnalités, en s'assurant qu'elles sont fonctionnelles et conviviales - peut-être même des sources de fierté qu'il serait heureux de mettre en avant sur son CV. Il est tout à fait normal pour un développeur de créer un excellent logiciel, de le livrer et de passer au projet suivant. À ce stade, les équipes de sécurité vérifient les vulnérabilités et, si elles en trouvent, leur application « terminée » peut être renvoyée à l'équipe pour un correctif. Le problème peut être simple, ou totalement hors de portée pour un développeur à corriger.

Le problème est qu'en surface, les failles de sécurité n'étaient pas du tout apparentes, et si l'analyse, les tests et la revue de code manuelle ne parviennent pas à les détecter, un attaquant peut potentiellement utiliser cette petite fenêtre d'opportunité pour exploiter la faille.

Désormais, Rust cherche à empêcher de nombreuses vulnérabilités de se retrouver dans le code dès le départ : il refuse tout simplement de compiler s'il y a des erreurs de syntaxe ou d'autres problèmes de sécurité mémoire qui causent des problèmes en production tout au long du cycle de vie du développement logiciel (SDLC). Il s'agit d'une programmation sécurisée en mémoire par conception, garantissant l'absence d'accès à une mémoire invalide (quelle que soit la manière dont le logiciel est exécuté). Et avec 70 % de toutes les failles de sécurité résultant de problèmes liés à la gestion de la mémoire, c'est un exploit remarquable.

Rust signalera et empêchera :

• Le dépassement de tampon
• L'utilisation après libération
• La double libération
• Le déréférencement de pointeur nul
• L'utilisation de mémoire non initialisée

Si nous comparons un extrait de code Rust avec du C++, il devient évident que l'un est sécurisé par défaut. Découvrez cet exemple de faille de dépassement de tampon :

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // dépassement de tampon car la longueur de b est supérieure à celle de a
std::cout << a << "; " << b << std::endl;
}

Vs.

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rust émet un avertissement de sécurité et provoque une panique lors de l'exécution de la fonction copy_from_slice pour empêcher tout dépassement de tampon, mais pas lors de la compilation.

En ce sens, c'est vraiment l'un de ces langages qui « partent de la gauche ». Il met en évidence les erreurs et force les développeurs à apprendre la bonne manière d'écrire du code pour éviter d'introduire des failles de sécurité liées à la mémoire. Le respect des délais dépend donc de la vigilance du développeur, de sa capacité à corriger les problèmes et à rester fidèle au processus de livraison.

L'approche de ce langage semble simple, mais il aurait été incroyable de parvenir à un tel résultat avec une logique aussi puissante, et il tient ses promesses. Rust représente, du point de vue de la sécurité, un bond en avant gigantesque... si seulement davantage de personnes l'utilisaient. Des entreprises comme Dropbox ouvrent la voie à son utilisation à grande échelle, ce qui est très encourageant. Cependant, il faut prendre en compte d'autres facteurs avant de conclure que seul un problème d'adoption nous sépare d'un avenir plus sûr.

L'heure de vérité pour Rust.

Il existe quelques petits (d'accord, gros) problèmes : programmer en Rust offre plus de latitude pour introduire des bugs qu'il n'y paraît. Il ne résoudra pas les vulnérabilités cruciales du Top 10 de l'OWASP qui continuent de provoquer des failles, des retards et une culture générale de techniques de codage non sécurisées. Il existe également une dynamique entre le bien et le mal, ou, comme on l'appelle plus communément : Safe Rust vs. Unsafe Rust.
‍

Comme l'explique la documentation officielle, le Safe Rust est la forme « pure » de Rust, tandis que l'Unsafe Rust inclut des fonctions jugées « définitivement non sûres », bien qu'elles soient parfois nécessaires, par exemple pour une intégration avec un autre langage. Cependant, même avec l'Unsafe Rust, la liste des fonctionnalités supplémentaires reste limitée. En Unsafe Rust, il est possible d'effectuer les opérations suivantes au sein de blocs unsafe :

• Déréférencer des pointeurs bruts
• Appeler des fonctions unsafe (y compris des fonctions C, des intrinsèques du compilateur et l'allocateur brut)
• Implémenter des traits unsafe
• Modifier des variables statiques
• Accéder aux champs d'unions.

Même dans ce mode dit « unsafe », l'un des super-pouvoirs de la programmation en Rust reste actif : le « borrow checker ». Il prévient généralement les problèmes de mémoire, les collisions dans les calculs parallèles et bien d'autres bugs grâce à l'analyse statique du code. Cette analyse continue d'effectuer des vérifications dans un bloc unsafe ; cela demande simplement beaucoup plus d'efforts pour écrire des constructions unsafe sans que le compilateur n'intervienne pour guider le développeur dans certaines situations.

Cela ne semble pas être un problème majeur pour la plupart des développeurs expérimentés — après tout, nous sommes connus pour bricoler afin de tirer le meilleur parti de nos applications et débloquer des fonctions plus avancées — mais cela ouvre potentiellement une boîte de Pandore pouvant mener à de graves erreurs de configuration et vulnérabilités : le comportement indéfini. Programmer en Rust (même en mode unsafe) limite assez bien les risques de vulnérabilités par rapport au C ou au C++, mais invoquer un comportement indéfini peut être risqué.

Est-ce la fin de la dépendance au codage sécurisé par le développeur ?

Vous souvenez-vous quand je disais plus tôt que Rust possède des composants de langages bien connus ? L'une des principales vulnérabilités de sécurité de Rust est, eh bien, qu'il contient des composants de langages bien connus, à savoir le C.

Rust reste un « langage de programmation sûr », mais là encore, l'intervention de l'utilisateur peut tout faire basculer. Le développeur peut toujours le modifier pour qu'il s'exécute sans signaler d'erreurs (une perspective séduisante, car cela débloque davantage de capacités). Essentiellement, même dans un état sûr, les développeurs peuvent être aussi « imprudents » qu'ils le souhaitent, car ils bénéficient d'une couche de conseils et de protection avant que les choses ne tournent vraiment mal.

Et les deux scénarios ci-dessus deviennent plus dangereux à mesure que nous creusons, car les résultats de Rust sont similaires aux outils d'analyse : tout comme il n'existe pas d'outil SAST/DAST/RAST/IAST universel capable de détecter chaque vulnérabilité, chaque vecteur d'attaque et chaque problème, Rust ne le fait pas non plus. Même avec Rust, certaines vulnérabilités peuvent encore être introduites assez facilement.

Le risque de comportement indéfini lors de l'exécution d'Unsafe Rust peut ouvrir la porte à des problèmes de dépassement d'entier, tandis qu'en général, même les configurations sûres n'empêcheront pas l'erreur humaine dans les mauvaises configurations de sécurité, la logique métier, ou l'utilisation de composants présentant des vulnérabilités connues. Ces problèmes constituent toujours une menace réelle s'ils ne sont pas corrigés, et dans un environnement « supposé sûr » comme Rust, cela peut même engendrer une certaine complaisance si un développeur pense que tous les problèmes majeurs seront détectés quoi qu'il arrive.

J'ai trouvé que Rust ressemble à un mentor en programmation : un ingénieur senior qui a pris le temps de s'asseoir avec un développeur moins expérimenté, de revoir son travail, de lui montrer des bugs potentiels, de souligner des pistes d'optimisation et, dans certains cas, de s'assurer que le code n'est compilé que lorsqu'il est correct. Cependant, il est bien préférable que les programmeurs Rust apprennent la théorie et s'engagent eux-mêmes à suivre les meilleures pratiques, car ce mentor pourrait bien vous laisser voler de vos propres ailes, et vous ne voulez pas vous retrouver démuni.

Prêt à trouver et à corriger les vulnérabilités courantes de Rust dès maintenant ? Relevez le défi.