Le langage, initialement créé par Mozilla et maintenant géré par une fondation indépendante, n’en finit plus de faire parler de lui.
Google vient ainsi d’apporter son soutien financier à Rustls, une alternative à OpenSSL écrite en Rust par Dirkjan Ochtman. L’annonce est faite par l’ISRG (Internet Security Research Group), qui s’en frotte les mains.
Elle est liée à une autre annonce, faite en janvier par le groupe, qui va rendre l’implémentation de httpd par Apache HTTP Server plus sécurisée par l’emploi, justement, de Rustls.
Selon l’ISRG, de nombreuses bibliothèques SSL/TLS ont un long sillage de vulnérabilités à cause de leur écriture en C. L’utilisation de Rust, langage memory safe, permet de se débarrasser de toute une classe de failles, réduisant significativement selon le groupe le nombre total de brèches.
Chez Google, on se félicite bien sûr : « Nous dépendons tous des logiciels open source pour construire le tissu d’internet et nous avons tous en conséquence une responsabilité de protéger et soutenir ces technologies, afin que l’innovation continue à prospérer. Soutenir l’ISRG et le travail de Dirkjan sur Rustls est une étape importante dans cette direction […]. »
Commentaires (16)
#1
C’est cool, mais ça leur coute combien ? peanuts
#1.1
Moins que ça ne leur rapporte. Ils ne financent pas un projet par bonté de coeur ;)
#2
Rust va-t-il progressivement remplacer le langage C dans tous les softs/libs liés à l’IT ?
Surement…
#3
N’étant pas trop renseigné dans le monde du dev et la cyber sécurité. Les failles mémoires sont-elles les plus courantes et les plus dangereuses ?
Y a-t-il des statistiques sur les failles importantes et critiques sur le type de failles ?
Afin de savoir si coder en Rust pourrait diminuer considérablement le nombre de failles.
#3.1
Je ne sais pas si ça réduira le nombre de faille, mais en tout cas elles ne seront plus de la faute du développeur codant en rust (tout comme pour java, python et d’autres langages).
Par contre, une faille au niveau du compilateur sera nettement plus grave, car impactant tous les projets utilisant celui-ci.
#3.2
C’est malheureusement bien plus compliqué que cela. Une faille comme heartbleed par exemple (qui est la plus médiatique) n’est pas stricto sensu due à un dépassement de buffer; le buffer a la bonne taille, il se fait simplement qu’il n’est pas rempli jusqu’au bout. La même implémentation, codée en Rust, aurait sans doute leaké tout autant, car les mécanismes de Rust n’auraient pas détecté de pointeur vagabond.
#3.3
Une faille mémoire, c’est très dangereux. Ca peut donner accès à intégralité d’un PC à un inconnu. Pour donner un exemple, la Wii à été piraté grâce à un dépassement de tampon (écrire au delà ce que le développeur* avait prévu.) Twilight Hack . Tu comprends vite que dès lors que tu peux faire exécuter n’importe quel code à une machine, c’est open bar.
Pas forcément, le classique qu’on apprend, c’est d’écrire directement une chaine de caractère en provenance de l’utilisateur sans vérifier que l’on a assez de place dans la table pour la sauvegarder entièrement. Mais de manière général, dès lors que tu utilise un array, ça implique des histoire de pointeurs et d’indirection et donc un truc qui peut aller au moindre problème se balader dans des endroits pas prévu (tu alloues alors de l’espace pour une variable du type U).
Pour le C++, je cite l’auteur du langage lui même “Avec C, il est facile de se tirer une balle dans le pied, C++ rend ça plus difficile mais lorsque tu y arrives, tu t’explose la jambe entière.” (“C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off”)
C++ n’est pas spécialement centrée sur la sécurité. Ce n’est pas spécialement son but et il est facile de faire des conneries. Il n’y a pas spécialement de sécurité supplémentaire par rapport à C (vu qu’il est grandement compatible). Le langage et la bibliothèque standard offre des outils qui rendent les erreurs plus évitable, mais ne les rend pas impossible.
Au contraire, Rust, de ce que j’ai rapidement lu est justement centré sur un sécurité de l’accès à la mémoire. En soit, ça ne rend pas le langage très agréable à utiliser au quotidien, mais offre la sécurité que tu n’as pas fait de la merde avec tes variable si ton code compile.
#4
J’avais lu quelque part que 70 % des failles de l’histoire de Chrome étaient mémoires
https://www.chromium.org/Home/chromium-security/memory-safety
#5
C’est les maloc/free qui posent problème?
ou c’est plus poussé que ça?
Rust est plus “fiable” que le C++ de ce point de vu là?
#5.1
Oui, c’est plus poussé que ca. Typiquement les cas des « race conditions » par exemple lors que tu fais de la programmation concurrente.
Rust est plus fiable dans le fait que le compilateur empêche que ce genre de cas arrive. C’est donc « plus contraignant » d’écrire un logiciel en Rust car le compilateur vérifie plus de choses, ce qui en résulte par une « fiabilité » plus importante que le C/C++.
#6
Statistiquement oui. La plus grande base du code existant dans le monde a été écrit dans des langages qui font reposer la bonne gestion de la mémoire sur celui qui écrit le code. C’est très facile de se tromper ou d’être fainéant, les conséquences sont presque toujours désastreuses à long terme (la sagesse populaire que toute faille mémoire peut toujours mener à la prise de contrôle par l’attaquant - ce n’est qu’une question de temps pour trouver la méthode).
Oui il y a des stats, mais comme ce n’est plus mon cœur de métier depuis quelques temps mes sources se sont taries. :-) Mais je peux quand même te dire que oui, coder dans un langage qui reprend la main sur la sécurisation des accès et des réservation de mémoire diminue considérablement le nombre de failles.
#7
Ce raisonnement est valable pour tous les langages compilés. Aussi bien Rust que le C. Ce n’est donc pas plus grave pour l’un que pour l’autre.
Et on peut même retourner l’argument: si une faille dans le compilateur est trouvée et corrigée, il “suffit” de recompiler les applis pour corriger toutes les instances de vulnérabilités qui avaient été introduites par le bug.
#7.1
La différence est que le compilateur Rust en fait beaucoup plus que les autres, ce qui explique d’ailleurs le temps de compilation
#8
#8.1
Le fait que le compilateur Rust soit écrit en Rust ne protège en rien le binaire généré.
#8.2
Le fait que le compilateur Rust soit écrit en Rust fait qu’il est beaucoup plus résistant face à une tentative délibérée de lui faire cracher du code vérolé via un dépassement de buffer.
C’est assez vain, puisque le code source qui fera ainsi planter le compilateur aura très probablement une structure très particulière, qu’un réviseur humain trouvera particulièrement suspecte… Genre une expression arithmétique sur 4 pages, un identificateur de 65 caractères.
Pour le reste, si le compilateur choisit par erreur d’utilier un registre 32 bits pour y mettre une valeur de 64 bits, qu’il soit écrit en C ou en Rust n’y changera pas grand chose.