IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le C est-il adapté à la création d'applis sécurisées ? La moitié des vulnérabilités de Curl résulterait d'erreurs de programmation dans ce langage
Auquel de plus en plus d'acteurs préfèrent le Rust

Le , par Patrick Ruiz

6PARTAGES

16  0 
Le développement du système UNIX a débuté en 1969 et son code a fait l’objet de réécriture en langage C en 1972. Ça fait donc des années que ce langage fait ses preuves : c’est un niveau de performances proche de celui de l’assembleur, ce, tout offrant flexibilité et productivité. Pourtant, de plus en plus de gros acteurs de la filière technologique lui préfèrent le Rust. Motif : le langage de Mozilla offrirait en plus de meilleurs gages pour la sécurisation des logiciels. Qu’est-ce qu’il en est ?



Ces dernières années, des chercheurs en sécurité ne cessent de mettre le doigt sur ce qui serait l’une des plus grosses tares que le langage C traîne : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon. Ces chiffres prennent un coup de neuf avec un plus récent état des lieux des vulnérabilités de l’utilitaire ligne de commande Curl utile pour récupérer le contenu d'une ressource accessible par un réseau informatique. De récents décomptes font état de ce qu’un peu plus de la moitié des failles de sécurité de Curl sont la résultante d’erreurs de programmation en langage C. En fait, la part cumulée de toutes les vulnérabilités de sécurité dues aux erreurs C au fil du temps (ligne bleue) était sous la barre des 50 % en 2012 pour repasser au-dessus en 2018. Depuis lors, elle y est demeurée.



C’est la raison pour laquelle de plus en plus de grands acteurs de la filière technologique lui préfèrent le langage Rust de Mozilla. Dans le cadre d’une présentation de la conférence virtuelle AllThingsOpen à mi-parcours de l’année précédente, Ryan Levick – développeur qui travaille sur l’infrastructure cloud du géant technologique (Microsoft) – revient sur ces détails et coupe court : « Quels que soient les investissements que les entreprises de la filière du développement de logiciels peuvent mettre sur pied, le fait est que C++ [C] n’est pas par essence un langage fait pour la mise sur pied d’applications sécurisées. » En 2019, Alex Gaynor – un ex-contributeur de l’équipe sécurité du navigateur Firefox – émettait un avis similaire : « Le C++ moderne ne nous sauvera pas, car il est moins sécurisé que les nouveaux langages [Rust, Swift]). »

L’une des approches envisageables est de multiplier les formations des programmeurs à l’écriture d’applications sécurisées en langage C. Une autre est de faire recours à l’analyse statique. Enfin, la piste des vérifications lors de l’exécution reste valable. Mais l’ingénieur de Microsoft est d’avis qu’aucune de ces solutions n’apporte une solution entière à l’absence d’orientation des langages C et C++ vers la sécurité dans leur conception. C’est pour cet ensemble de raisons que ce dernier estime que le langage Rust est la meilleure chance offerte à l’industrie informatique pour la mise sur pied d’applications sécurisées.

Les initiatives allant dans le sens de faire un usage plus extensif du langage se multiplient donc chez la firme de Redmond. L’une des plus récentes et remarquées est Rust/WinRT – une projection du langage Rust pour les API Windows Runtime. De façon ramassée, l’annonce signifie que les développeurs peuvent créer des composants pour Windows en utilisant Rust. En parallèle, Microsoft pilote l’effort « Safe Systems Programming Languages » au travers duquel l’entreprise apporte plus d’éclaircissements sur son intérêt pour des langages de programmation comme Rust.


Les initiatives allant dans le sens de faire un usage plus extensif du langage se multiplient donc chez la firme de Redmond. L’une des plus récentes et remarquées est Rust/WinRT – une projection du langage Rust pour les API Windows Runtime. De façon ramassée, l’annonce signifie que les développeurs peuvent créer des composants pour Windows en utilisant Rust. En parallèle, Microsoft pilote l’effort « Safe Systems Programming Languages » au travers duquel l’entreprise apporte plus d’éclaircissements sur son intérêt pour des langages de programmation comme Rust.

Sur cinq années consécutives, Rust a obtenu la reconnaissance de « plus aimé » des développeurs habitués de la plateforme de questions-réponses sur des sujets liés à l’informatique – StackOverflow. Toutefois, ce dernier reste très utilisé dans le cadre de projets personnels. Les entreprises ne s’en servent pas. En toile de fond, on a un lot de raisons techniques susceptibles de justifier le positionnement des entreprises qui ne s’appuient pas sur Rust pour leurs projets : manque de bibliothèques, absence de prise en charge de plus d’ environnements de développement intégré, manque de documentation, etc. En effet, le manque de bibliothèques est l’une des raisons que certains développeurs soulignent comme un frein à la productivité.

Après, Rust a désormais l’un des plus grands de l’histoire de l’informatique pour le pousser. Ce sont des ressources supplémentaires qui peuvent être allouées à l'amélioration et au développement du langage lui-même : du temps d'ingénierie, probablement des propositions et pistes d'amélioration. En sus, l’appui de Microsoft apparaît comme une étiquette qualité pour le langage de programmation. Cela devrait permettre de rehausser son niveau d’adoption en entreprise.

Sources : État des lieux (1, 2)

Et vous ?

Le langage C est-il adapté à la mise sur pied d’applications sécurisées ?
Êtes-vous en accord avec les griefs portés à l'endroit du langage C en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Voyez-vous aussi la présence de Microsoft derrière ce langage comme une force ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, sur des projets de quelle taille ?
Quels sont les ingrédients susceptibles de conduire à une adoption plus importante de Rust, mais qui lui font encore défaut de votre point de vue ?

Voir aussi :

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 10/03/2021 à 20:11
Citation Envoyé par ijk-ref Voir le message
C'est un classique, dans toutes conversations sur un nouveau langage, il y en a toujours pour dire qu'on peut déjà tout faire en assembleur.
Et réciproquement : certains sont tellement en adoration de leur nouveau langage qu'ils n'en acceptent aucune critique

Alors que ça devrait juste être considéré comme ce que c'est : des outils avec des avantages et des inconvénients...
7  0 
Avatar de walfrat
Membre éprouvé https://www.developpez.com
Le 10/03/2021 à 9:50
C représente 50% des erreurs de sécurité ? OK mais combien de % de volume de code représente-t-il par rapport aux autres langages ? Histoire d'avoir une image plus juste de la situation


Le langage C est-il adapté à la mise sur pied d’applications sécurisées ?
Sur un aspect purement technique, il est évidemment plus simple de le faire avec des langages plus récent, mais qui perdent certains avantage du C. En même temps si les nouveaux n'avaient rien a apporté 40 ans après le C, ce serait dommage.


Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
La qualité des développeurs, mais aussi les moyens (budget/temps) qu'on leur donne et donc généralement le fait que tout ce qui n'ait pas visible n'est pas prioritaire dans un projet.


Voyez-vous aussi la présence de Microsoft derrière ce langage comme une force ?
J'aurais préféré cité Linus Torvald, célèbre pour avoir aussi rejeté beaucoup de langage récent car ceux-ci n'étant pas adapté aux besoin du système (de mémoire).


Votre entreprise a-t-elle adopté le langage Rust ? Si oui, sur des projets de quelle taille ?
Je fais du web / client lourd avec cartographie, donc non.


Quels sont les ingrédients susceptibles de conduire à une adoption plus importante de Rust, mais qui lui font encore défaut de votre point de vue ?
Plus de librairies, mais comme toujours ils y en aura plusieurs qui apparaîtront et on retrouvera les classique problèmes de dépendances et d'interdépendances qui changes au fur et a mesure de l'évolution de celle-ci. Par exemple, j'ai monté de version Hibernate récemment, et j'ai du changé des dépendances annexes qui avaient évoluée du fait de la fusion Lucène/Solr et changé les import en conséquence. Heureusement pour moi ça c'est limité à cela.

En outre il y a aussi le problème de la sécurité des dépendances.
6  0 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 10/03/2021 à 13:59
Citation Envoyé par Markand Voir le message
Il est évident qu'il est plus facile de faire des erreurs en C que dans un autre langage, mais en Rust vous pouvez aussi écrire des conneries. Si vous faites une erreur dans le code d'authentification d'un utilisateur et que votre application vous permet d'obtenir accès total à un système on va dire que c'est la faute au programmeur, par contre à un programme en C on va dire que c'est la faute du C.

Les toolchains ont bien évolué et avec une quantité élevée de tests, de linter, de static analyser et de sanitizers on peut écrire du code robuste en C. Encore faut-il tester son application.

Le noyau Linux, *BSD et d'autres systèmes sont écrit 100% en C et font tourner les plus gros datacenter du monde (quand ils ne partent pas en fumée) alors il y a bien la preuve qu'on peut écrire du code robuste en C.

Pour le cas de CURL, il faut bien prendre en compte que c'est un logiciel énorme. Il implémente une tonne de protocoles, une tonne d'implémentation différentes des bibliothèques de chiffrement (on s'éloigne du principe KISS d'ailleurs). Plus il y a de code, plus il y a de risque d'erreur. Et contrairement à un projet comme Linux il y a bien moins de monde qui audit son code.
En fait tu n'a pas lu l’article non ? Malgré tout le soin apporté au code source de Curl (qui comme Linux est plutôt une exception qu'une règles car bon nombre de base de code en C étant bien pire) la moité des bugs de sécurité trouvés sont dues à la nature unsafe de C. Et d'ailleurs l'article de base parle d'analyse statique et tout le tintouin. Pourtant des bugs de sécurité s'ont passé à travers les failles du filets. Et c'est d'ailleurs la même chose pour Linux, qui a des failles du même acabits. C'est d'ailleurs aussi vrai pour Windows qui avait fait des statistiques sur ses failles de sécurité et les chiffres étaient les mêmes. Bref, cela prouve qu'une bonne partie des failles de sécurité (la moitié) sera toujours dues à l'utilisation du langage C/C++. Dernièrement, tu confonds robustesse pour une utilisation de tous les jours, et robustesse à une attaque. Mon PC Windows, n'a pas eu de problème de sécurité depuis son installation il y a 5 ans. Il est donc robuste pour une utilisation de tous les jours. Ce n'est pas pour autant que si des gens compétents et motivés voulaient rentrer dessus via une faille 0-day, ils n'y arriveraient pas.
5  1 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 10/03/2021 à 20:24
Le langage C est-il adapté à la mise sur pied d’applications sécurisées ?

Ça sa va dépendre des moyens mis en œuvre sur le projet, mais je dirais qu'a moyens égaux, un projet codé en C sera toujours moins safe que sont équivalent en Rust.
Maintenant, si le côté safe avait été une vrai valeur ajouter pour eux, pourquoi Ada n'as pas eu plus de succès que ça, surtout depuis Ada 2012 ?

Êtes-vous en accord avec les griefs portés à l'endroit du langage C en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?

Le problème du C comme déjà lu ici, c'est qu'a effort de programmation équivalent (donc pour une même équipe), il donnera forcement de moins bon résultats concernant la sécurité qu'un langage avec des garantie native comme peut l'être Rust.

Maintenant, on peut toujours critiqué le C, "n' empêche" il est toujours le meilleur dans ceux pour quoi il a été conçu, soit s'interfacer avec le hardware sans recoure systématique à l'assembleur natif de la plateforme.

Bon, c'est également vrai que les développeurs compétents en C/C++ (à un niveau d'efficacité pro), ça court pas les rues non plus, mais à raison.
En effet combien de projets nécessite de taper si bas niveau ? Et pour quel niveau de productivité ?
La grande majorité des projet en Entreprise ne nécessite pas un tel niveau d'optimisation et ce contente largement du Java ou de .Net pour être beaucoup plus productif (ou autre ).

C'est aussi vrai dans d'autres domaines.
En générale, combien de chercheurs, pour combien d'ingénieur, pour combien de techniciens dans un environnement pro ?
C'est pareil avec les langages bas niveau, combien de développeur de drivers ou d'OS, pour combien de développeur applicatifs ?
Les uns ne sont pas "meilleurs" que les autres, ils ne font juste pas le même boulot.

Maintenant que la sécurité (re)deviennent une priorité pour de grandes boites, c'est bien qu'elles se sont aperçues que ça leurs couté de l'argent et donc que le cout d’exploitation du langage C/C++ commence à dépasser ses avantages qui sont quand même énorme (base de code en production, audité depuis plusieurs années et qui font le job).

Voyez-vous aussi la présence de Microsoft derrière ce langage comme une force ?

Oui, forcement ça légitime un peut plus le langage en Entreprise, mais ça ne garanti pas non plus son succès.
Ce sera plus au niveau de ses lib que l'on verra si le langage est adopté ou non par l'industrie.

Votre entreprise a-t-elle adopté le langage Rust ? Si oui, sur des projets de quelle taille ?

Non, mais je suis dans le web (HTML5, Node/Python/PHP, Go & un chouia d'Elixir & Dart pour test) et je ne code qu'a titre personnel au niveau système (C, Pascal, Rust, ...etc VHDL ).
Remarquez qu'avec WASM il faudra bien s'y mettre (j’espère).

Quels sont les ingrédients susceptibles de conduire à une adoption plus importante de Rust, mais qui lui font encore défaut de votre point de vue ?

L’interopérabilité avec des libs / environnements existant je pense, mais c'est pareil pour tout nouveau langage.
Si personne n'avait fait de lib pour Node est ce que vous l'utiliseriez vraiment ?
Personnellement, c'est un gros NON d'autant qu'une plateforme qui ce veut Back mais n'est pas "battery included", c'est limite foutage de gueule (surtout lors de sont lancement), mais bon, aujourd'hui vous ne pouvez plus faire du web sans lui car toutes les toolchain l'utilise d'une façon ou d'une autre au finale.

P.S. : On est d'accord que c'est aussi le faite de la profusion de dev JS préexistant qui à rendu Node obligatoire aujourd'hui, là ou Rust doit vraiment faire ses preuves dans tous les domaines pour vraiment "remplacer" C &/ou C++.

P.S. 2 : Rust offrant un niveau d'abstraction assez élever au besoin, peut tout à fait remplacer Go, Python ou autre côté Back (cf. Rocket.rs, encore en bêta mais très prometteur).
4  0 
Avatar de smarties
Membre éclairé https://www.developpez.com
Le 10/03/2021 à 10:51
Le langage C est-il adapté à la mise sur pied d’applications sécurisées ?
Avec des jeux de test et des méthodes de validation on peut s'en sortir mais ce n'est pas parfait non plus.
Je pense que C a fait son temps et pour les applications sans GUI, Rust se débrouille très bien.

Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Je suis d'accord avec ce qui a été dit, il y a le rapport budget/temps à prendre en compte. Ensuite, quand des problèmes sont récurrent sur un programme il faut s'accorder du temps pour faire bien les choses une fois et ne pas faire le pompier à chaque fois.

Voyez-vous aussi la présence de Microsoft derrière ce langage comme une force ?
Oui, le fait qu'il y ait des géants qui l'adopte va attirer des développeurs.

Votre entreprise a-t-elle adopté le langage Rust ? Si oui, sur des projets de quelle taille ?
Non, le logiciel est trop gros. De plus, on a besoin de faire des interfaces Windows.

Quels sont les ingrédients susceptibles de conduire à une adoption plus importante de Rust, mais qui lui font encore défaut de votre point de vue ?
Les librairies. Il en faudrait surtout une graphique multiplateforme qui se démarque.
3  0 
Avatar de Markand
Membre éclairé https://www.developpez.com
Le 10/03/2021 à 13:31
Il est évident qu'il est plus facile de faire des erreurs en C que dans un autre langage, mais en Rust vous pouvez aussi écrire des conneries. Si vous faites une erreur dans le code d'authentification d'un utilisateur et que votre application vous permet d'obtenir accès total à un système on va dire que c'est la faute au programmeur, par contre à un programme en C on va dire que c'est la faute du C.

Les toolchains ont bien évolué et avec une quantité élevée de tests, de linter, de static analyser et de sanitizers on peut écrire du code robuste en C. Encore faut-il tester son application.

Le noyau Linux, *BSD et d'autres systèmes sont écrit 100% en C et font tourner les plus gros datacenter du monde (quand ils ne partent pas en fumée) alors il y a bien la preuve qu'on peut écrire du code robuste en C.

Pour le cas de CURL, il faut bien prendre en compte que c'est un logiciel énorme. Il implémente une tonne de protocoles, une tonne d'implémentation différentes des bibliothèques de chiffrement (on s'éloigne du principe KISS d'ailleurs). Plus il y a de code, plus il y a de risque d'erreur. Et contrairement à un projet comme Linux il y a bien moins de monde qui audit son code.
5  2 
Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 11/03/2021 à 11:19
Citation Envoyé par vivid Voir le message
Avé frater

Cela me rappelle tout les tacherons qui voulait couper les platanes au bords des routes, sous prétexte que la route était accidentogène, 'une route accidentogène' ce genre de personne on due déjà voir des platanes traverser la route. Pour tout ces gens je leur recommande plutôt la marche a pied

ici c'est le même principe. Mauvaise maitrise...
Je rajoute que cela irait dans l’intérêt de certaine catégories de personnes de niveler par le bas les compétences. (ceux qui aime pas programmer, les incompétents, les entreprises pour faire des économies (compétences moindre, forcement))

bye.
Les seules personnes qui peuvent se venter de n'avoir fait aucune erreur en C sont ceux qui ne l'ont jamais utiliser. Et ça vaut pour tous les langages, sauf que certaines évitent des classes d'erreurs entière en contrôlant ou ne laissant pas la main sur la mémoire au programmeur.
3  0 
Avatar de puffola
Membre du Club https://www.developpez.com
Le 10/03/2021 à 11:16
Quels sont les ingrédients susceptibles de conduire à une adoption plus importante de Rust, mais qui lui font encore défaut de votre point de vue ?
la disponibilité le GUI cross-platform avec le binding, composants complets (datepicker, etc.)
2  0 
Avatar de mith06
Membre éclairé https://www.developpez.com
Le 10/03/2021 à 9:50
1ère étape comprendre le code que l'on écrit.
2ème étape activer et corriger les warnings à la compilation (et accessoirement comprendre pourquoi le warning est généré).
3ème étape éviter d'utiliser les fonctions propices au buffer overflow (ex gets sprintf et autres...).
2  1 
Avatar de ijk-ref
Membre confirmé https://www.developpez.com
Le 10/03/2021 à 16:26
Citation Envoyé par Markand Voir le message
Le noyau Linux, *BSD et d'autres systèmes sont écrit 100% en C et font tourner les plus gros datacenter du monde (quand ils ne partent pas en fumée) alors il y a bien la preuve qu'on peut écrire du code robuste en C.
En gros, tu nous dis qu'on peut aussi faire du code robuste en Assembleur. Tu n'as donc rien compris à l'intérêt d'un langage de haut niveau. Son intérêt n'est pas de POUVOIR mais de DEVOIR faire un code robuste.
1  0