Rust est le langage de programmation le plus apprécié pour la cinquième fois. Est-ce 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 se lassent tout simplement pas de Rust pour la programmation. Ce langage de programmation de systèmes relativement nouveau, produit par Mozilla, a conquis le cœur de la communauté de Stack Overflow et, en tant que cohorte, il est peu probable qu'elle soit stupide lorsqu'elle vote pour un vote, le »langage de programmation le plus apprécié« Cinq années de suite, il est temps que nous prenions tous la parole et que nous en prenions note.

Le langage de programmation Rust intègre des éléments connus et fonctionnels issus de langages couramment utilisés, selon une philosophie différente qui élimine la complexité, tout en introduisant performance et sécurité. C'est une courbe d'apprentissage, et de nombreux développeurs n'ont pas vraiment l'occasion de jouer avec elle - seulement 5,1 % des personnes interrogées sur Stack Overflow couramment utilisé. Cela mis à part, il est indéniable qu'il s'agit d'un langage passionnant, doté d'une puissance de sécurité bien supérieure à celle de ses prédécesseurs, tels que le C et le C++. L'adoption massive va nécessiter des changements, à la fois comportementaux et technologiques... mais pour l'instant, elle attire toujours l'attention des développeurs sur le plan théorique.

... mais attendez, nous devons mettre en lumière une dernière chose : il est important de noter que Rust est un langage de programmation qui donne la priorité à la sécurité de la mémoire et à l'éradication des bogues de sécurité associés à des problèmes courants de gestion de la mémoire. C'est un gros problème (et cause sans aucun doute de nombreuses migraines pour les équipes AppSec), mais ce ne sont pas les seuls défis auxquels nous sommes confrontés en matière de codage sécurisé.

Qu'est-ce que Rust prévient exactement ? Et où sommes-nous encore exposés dans le paysage de la sécurité ? Découvrons la dernière licorne en matière de programmation :

La nouvelle frontière de la programmation de systèmes modernes et sûrs pour la 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 d'introduction donne un aperçu de leur philosophie, avec un thème clé très clair : l'approche actuelle de la sécurité logicielle est imparfaite, et Rust est conçu pour résoudre une grande partie de ce problème.

Cela semble trop simpliste, d'autant plus que nous sommes confrontés à d'énormes violations de données tous les deux jours, tout comme la récente erreur horrible 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, mauvaise configuration de la sécurité, ou attaque de phishing, et des langages tels que le C++ existent depuis des décennies. Cependant, les développeurs n'ont pas eu assez de temps pour les maîtriser au point de mettre en œuvre les meilleures pratiques de codage sécurisé. Pourquoi Rust devrait-il être différent ? De nouveaux langages sont déjà apparus, et ce n'est pas comme s'ils avaient 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 surmonter des questions complexes. Rust est, dans tous les sens du terme, une révolution dans la programmation de systèmes à mémoire sécurisée qui tient ses promesses à bien des égards... et il permet certainement d'économiser du temps aux développeurs qui sont susceptibles d'introduire des erreurs susceptibles de provoquer de gros problèmes si elles ne sont pas détectées. Java, C, C++ et même des langages plus récents tels que Kotlin et Golang restent assez impitoyables pour les développeurs peu soucieux de la sécurité. Avec ceux-ci, il n'y a aucun avertissement intégré, aucun signe particulier indiquant que la fonctionnalité géniale qui vient d'être compilée cache un gremlin de sécurité sous le capot.

Alors, approfondissons :

Qu'est-ce qui rend Rust si sûr ?

En général, l'objectif principal d'un développeur est de créer des fonctionnalités, de s'assurer qu'elles sont fonctionnelles et conviviales. Peut-être même une source de fierté qu'il serait heureux de mettre en valeur 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 prochain grand projet. À ce stade, les équipes de sécurité vérifient les vulnérabilités et, si elles sont détectées, leur application « terminée » peut être renvoyée à leur équipe pour un correctif. Le problème peut être simple ou totalement hors de portée pour un développeur.

Le problème est qu'à première vue, les bogues de sécurité n'étaient pas du tout apparents, et si l'analyse, les tests et la révision manuelle du code ne parviennent pas à les détecter, un attaquant peut potentiellement profiter de cette petite fenêtre d'opportunité pour exploiter le bogue.

Maintenant, Rust cherche à empêcher de nombreuses vulnérabilités de pénétrer dans le code : il ne sera tout simplement pas compilé en cas d'erreurs de syntaxe ou d'autres bogues de sécurité de la mémoire qui entraînent des problèmes de production tout au long du SDLC. Il s'agit d'une programmation sécurisée de par sa conception, qui garantit qu'il n'y a aucun accès à une mémoire non valide (quelle que soit la manière dont le logiciel est exécuté). Et avec 70 % de tous les bogues de sécurité sont dus à des problèmes liés à la gestion de la mémoire, c'est une belle prouesse.

La rouille signalera et empêchera :

• Débordement de la mémoire tampon
• À utiliser gratuitement
• Doublement gratuit
• Déréférencement du pointeur nul
• Utilisation de la mémoire non initialisée

Si nous comparons un extrait de code Rust avec du C++, il deviendra évident qu'il est sûr par défaut. Découvrez cet exemple de bogue de dépassement de mémoire tampon :

#include<iostream></iostream>
#include<string.h></string.h>
int main (void) {
caractère a [3] = « 12" ;
caractère b [4] = « 123 » ;
strcpy (a, b) ;//dépassement de la mémoire tampon lorsque len de b est supérieur à a
std : :cout << a << « ;" << b << std : :endl ;
}

Contre.

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

Rust émet un avertissement de sécurité et panique lorsqu'il atteint la fonction copy_from_slice au moment de l'exécution pour éviter tout débordement de la mémoire tampon, mais pas au moment de la compilation.

En ce sens, c'est vraiment l'une des langues du « départ à gauche ». Il mettra en évidence les erreurs et apprendra aux développeurs la bonne façon d'écrire du code afin d'éviter d'introduire des bogues de sécurité liés à la mémoire. Le respect des délais dépend donc de l'attention du codeur, de la correction et de la fidélité au chemin de livraison.

L'approche de ce langage semble simple, mais cela aurait été un exploit incroyable de le faire fonctionner avec cette puissante logique, et il va de soi. Du point de vue de la sécurité, Rust représente un grand pas en avant... si seulement davantage de personnes l'utilisaient. Des entreprises comme Dropbox sont les premières à utiliser son utilisation à grande échelle, et c'est formidable à voir. Mais il y a d'autres considérations avant de conclure qu'un problème d'adoption est la seule chose qui nous empêche d'avoir un avenir plus sûr.

Les comptes de Rust.

Il y a quelques petits (d'accord, gros) problèmes, à savoir que la programmation dans Rust est plus flexible qu'il n'y paraît pour introduire des bogues. Ce sera pas corrigez les 10 principales vulnérabilités de l'OWASP qui continuent de provoquer des violations, des retards et une culture générale de techniques de codage dangereuses. Il existe également une sorte de dynamique entre les anges et les démons, ou, comme on le sait plus généralement : Safe Rust ou Unsafe Rust.
‍

Comme il est expliqué dans documentation officielle, Safe Rust est la « vraie » forme de Rust, et Unsafe Rust inclut des fonctions considérées comme « définitivement dangereuses », bien qu'elles soient parfois nécessaires, par exemple si l'intégration avec quelque chose dans un autre langage est requise. Cependant, même avec Unsafe Rust, la liste des fonctionnalités supplémentaires est encore limitée. Dans Unsafe Rust, il est possible d'effectuer les opérations suivantes dans des blocs non sécurisés :

• Déréférencer les pointeurs bruts
• Appelez des fonctions non sécurisées (y compris les fonctions C, les éléments intrinsèques du compilateur et l'allocateur brut)
• Implémenter des traits dangereux
• Muter la statique
• Accédez aux domaines des syndicats.

Même dans un mode dit « non sécurisé », l'un des super pouvoirs de la programmation Rust fonctionne toujours : le « vérificateur d'emprunt ». Elle permet généralement d'éviter les problèmes de mémoire, les collisions lors de calculs parallèles et de nombreux autres bogues grâce à l'analyse statique du code, et cette analyse permet tout de même d'effectuer des vérifications dans un bloc non sécurisé. L'écriture de constructions non sécurisées demande simplement beaucoup plus de travail sans que le compilateur n'intervienne pour vous guider 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 pour tirer le meilleur parti de nos applications et ouvrir des fonctions plus intéressantes, mais cela ouvre potentiellement un trou noir qui peut entraîner de graves erreurs de configuration et des failles de sécurité : un comportement indéfini. La programmation dans Rust (même lorsqu'elle n'est pas utilisée en toute sécurité) réduit assez bien les possibilités de vulnérabilités par rapport au C ou au C++, mais invoquer un comportement indéfini peut présenter un risque.

Est-ce la fin de la dépendance à l'égard du codage sécurisé piloté par les développeurs ?

Tu te souviens plus tôt quand j'ai dit que Rust avait des composants de langages connus ? L'une des principales failles de sécurité de Rust est qu'il contient des composants de langages bien connus, à savoir le C.

Rust est toujours un « langage de programmation sûr », mais encore une fois, c'est l'introduction d'un utilisateur qui permet de débloquer les choses. Le développeur peut toujours le modifier pour qu'il fonctionne sans signaler d'erreur (une proposition intéressante, car cela permet de débloquer plus de fonctionnalités), et essentiellement, même en toute sécurité, les développeurs peuvent toujours être aussi « dangereux » qu'ils le souhaitent, car ils disposent d'une couche de conseils et de protection avant que les choses ne prennent vraiment la forme d'une poire.

Et les deux scénarios ci-dessus deviennent de plus en plus dangereux à mesure que nous approfondissons, car les résultats de Rust sont similaires à ceux des outils d'analyse. Tout comme il n'existe aucun outil SAST/DAST/RAST/IAST de l'armée suisse qui analyse 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 comportemental non défini lors de l'exécution de Unsafe Rust peut entraîner des problèmes de dépassement d'entiers, alors qu'en général, même les configurations sûres n'empêcheront pas les erreurs humaines dans les mauvaises configurations de sécurité, logique métier, ou en utilisant des composants présentant des vulnérabilités connues. Ces problèmes constituent toujours une menace bien réelle s'ils ne sont pas corrigés, et dans un environnement « supposé sûr » comme True Rust, cela peut même entraîner un certain comportement complaisant si un codeur pense que tous les problèmes majeurs seront détectés malgré tout.

J'ai découvert que Rust n'est pas sans rappeler un mentor en programmation : un ingénieur senior qui a pris le temps de s'asseoir avec un codeur moins expérimenté, de passer en revue son travail et de lui montrer les bogues potentiels, de souligner les gains d'efficacité et, dans certains cas, de s'assurer qu'il n'est pas compilé tant qu'il n'est pas correct. Cependant, il vaut mieux que les programmeurs de Rust apprennent la théorie et s'engagent eux-mêmes à appliquer les meilleures pratiques, car ce mentor pourrait bien vous couper les ficelles du tablier et vous ne voudriez pas être laissé pour compte.

Êtes-vous prêt à identifier et à corriger les vulnérabilités courantes de Rust dès maintenant ? Relève le défi.