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 !

La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire
Pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels

Le , par Stéphane le calme

9PARTAGES

13  0 
La National Security Agency (NSA) a publié des conseils pour aider les développeurs et les opérateurs de logiciels à prévenir et à atténuer les problèmes de sécurité de la mémoire logicielle, qui représentent une grande partie des vulnérabilités exploitables. La fiche d'information sur la cybersécurité « Sécurité de la mémoire logicielle » souligne comment les cyberacteurs malveillants peuvent exploiter les problèmes de mauvaise gestion de la mémoire pour accéder à des informations sensibles, promulguer l'exécution de code non autorisé et causer d'autres impacts négatifs.

« Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui », a déclaré Neal Ziring, directeur technique de la cybersécurité. « Nous devons utiliser systématiquement des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants ».


La société moderne s'appuie fortement sur l'automatisation basée sur les logiciels, faisant implicitement confiance aux développeurs pour écrire des logiciels qui fonctionnent de la manière attendue et ne peuvent pas être compromis à des fins malveillantes. Alors que les développeurs effectuent souvent des tests rigoureux pour préparer la logique des logiciels à des conditions surprenantes, les vulnérabilités logicielles exploitables sont encore souvent basées sur des problèmes de mémoire. Les exemples incluent le débordement d'une mémoire tampon et l'exploitation des problèmes liés à la façon dont le logiciel alloue et désalloue la mémoire.

Microsoft a révélé lors d'une conférence en 2019 que, de 2006 à 2018, 70 % de leurs vulnérabilités étaient dues à des problèmes de sécurité de la mémoire. Google a également trouvé un pourcentage similaire de vulnérabilités de sécurité de la mémoire sur plusieurs années dans Chrome. Les cyber-acteurs malveillants peuvent exploiter ces vulnérabilités pour l'exécution de code à distance ou d'autres effets indésirables, qui peuvent souvent compromettre un appareil et être la première étape des intrusions réseau à grande échelle. Les langages couramment utilisés, tels que C et C++, offrent une grande liberté et une grande flexibilité dans la gestion de la mémoire tout en s'appuyant fortement sur le développeur pour effectuer les vérifications nécessaires sur les références mémoire.

De simples erreurs peuvent conduire à des vulnérabilités exploitables basées sur la mémoire. Les outils d'analyse logicielle peuvent détecter de nombreux cas de problèmes de gestion de la mémoire et les options d'environnement d'exploitation peuvent également fournir une certaine protection, mais les protections inhérentes offertes par les langages logiciels sécurisés pour la mémoire peuvent prévenir ou atténuer la plupart des problèmes de gestion de la mémoire.

La NSA recommande d'utiliser un langage sécurisé pour la mémoire lorsque cela est possible. Bien que l'utilisation de protections supplémentaires pour les langages non sécurisés pour la mémoire et l'utilisation de langages sécurisés pour la mémoire n'offrent pas une protection absolue contre les problèmes de mémoire exploitables, elles offrent une protection considérable.

Par conséquent, la communauté logicielle globale du secteur privé, du milieu universitaire et du gouvernement américain a lancé des initiatives visant à orienter la culture du développement logiciel vers l'utilisation de langages sécurisés dans la gestion de la mémoire.


Le problème de la sécurité de la mémoire

La façon dont un programme logiciel gère la mémoire est essentielle pour prévenir de nombreuses vulnérabilités et garantir la robustesse d'un programme. L'exploitation d'une gestion de la mémoire médiocre ou négligente peut permettre à un cyberacteur malveillant d'accomplir des actes néfastes, tels que planter le programme à volonté ou modifier les instructions du programme en cours d'exécution pour faire ce que l'acteur désire. Même des problèmes inexploitables avec la gestion de la mémoire peuvent entraîner des résultats de programme incorrects, une dégradation des performances du programme au fil du temps ou des plantages de programme apparemment aléatoires.

La sécurité de la mémoire est une vaste catégorie de problèmes liés à la façon dont un programme gère la mémoire. Un problème courant est appelé « débordement de tampon », où les données sont accessibles en dehors des limites d'un tableau. D'autres problèmes courants concernent l'allocation de mémoire. Les langages peuvent allouer de nouveaux emplacements de mémoire pendant l'exécution d'un programme, puis désallouer la mémoire, également appelée libération ou libération de la mémoire, plus tard lorsque la mémoire n'est plus nécessaire. Mais si cela n'est pas fait avec soin par le développeur, de la nouvelle mémoire peut être allouée encore et encore au fur et à mesure que le programme s'exécute. Par conséquent, la mémoire n'est pas toujours libérée lorsqu'elle n'est plus nécessaire, ce qui entraîne une fuite de mémoire qui pourrait entraîner le programme à manquer de mémoire disponible.

En raison d'erreurs logiques, les programmes peuvent également tenter d'utiliser la mémoire qui a été libérée, ou même de libérer de la mémoire qui a déjà été libérée. Un autre problème peut survenir lorsque les langages autorisent l'utilisation d'une variable qui n'a pas été initialisée, ce qui fait que la variable utilise la valeur précédemment définie à cet emplacement en mémoire. Enfin, un autre problème difficile est appelé une condition de concurrence. Ce problème peut se produire lorsque les résultats d'un programme dépendent de l'ordre de fonctionnement de deux parties du programme accédant aux mêmes données. Tous ces problèmes de mémoire sont des occurrences beaucoup trop courantes.

En exploitant ces types de problèmes de mémoire, les acteurs malveillants, qui ne sont pas liés par les attentes normales d'utilisation du logiciel, peuvent découvrir qu'ils peuvent entrer des entrées inhabituelles dans le programme, provoquant l'accès, l'écriture, l'allocation ou la désallocation de la mémoire de manière inattendue. Dans certains cas, un acteur malveillant peut exploiter ces erreurs de gestion de la mémoire pour accéder à des informations sensibles, exécuter du code non autorisé ou provoquer d'autres impacts négatifs. Puisqu'il peut falloir beaucoup d'expérimentation avec des entrées inhabituelles pour en trouver une qui provoque une réponse inattendue, les acteurs peuvent utiliser une technique appelée "fuzzing" pour créer de manière aléatoire ou intelligente une multitude de valeurs d'entrée dans le programme jusqu'à ce qu'on en trouve une qui provoque le plantage du programme.

Les progrès des outils et des techniques de fuzzing ont facilité la recherche d'entrées problématiques pour les acteurs malveillants ces dernières années. Une fois qu'un acteur découvre qu'il peut faire planter le programme avec une entrée particulière, il examine le code et travaille pour déterminer ce qu'une entrée spécialement conçue pourrait faire. Dans le pire des cas, une telle entrée pourrait permettre à l'acteur de prendre le contrôle du système sur lequel le programme s'exécute.


Langages sécurisés dans la gestion de la mémoire

L'utilisation d'un langage sécurisé pour la mémoire peut aider à empêcher les programmeurs d'introduire certains types de problèmes liés à la mémoire. La mémoire est gérée automatiquement dans le cadre du langage informatique ; il ne repose pas sur l'ajout de code par le programmeur pour implémenter des protections de mémoire. Le langage institue des protections automatiques en utilisant une combinaison de vérifications au moment de la compilation et de l'exécution. Ces fonctionnalités inhérentes au langage protègent le programmeur contre l'introduction involontaire d'erreurs de gestion de la mémoire. C#, Go, Java, Ruby, Rust et Swift sont des exemples de langage sécurisé pour la mémoire.

Même avec un langage sécurisé pour la mémoire, la gestion de la mémoire n'est pas entièrement sécurisée pour la mémoire. La plupart des langages de mémoire sécurisés reconnaissent que les logiciels doivent parfois exécuter une fonction de gestion de mémoire non sécurisée pour accomplir certaines tâches. En conséquence, des classes ou des fonctions sont disponibles qui sont reconnues comme non sécurisées pour la mémoire et permettent au développeur d'effectuer une tâche de gestion de la mémoire potentiellement dangereuse. Certains langages exigent que tout ce qui n'est pas sûr en mémoire soit explicitement annoté comme tel pour que le développeur et tous les réviseurs du programme sachent qu'il n'est pas sûr. Les langages sécurisés pour la mémoire peuvent également utiliser des bibliothèques écrites dans des langages non sécurisés pour la mémoire et peuvent donc contenir des fonctionnalités de mémoire non sécurisées. Bien que ces façons d'inclure la mémoire ne soient pas sûres et subvertissent la sécurité inhérente à la mémoire, elles aident à localiser où des problèmes de mémoire pourraient exister, permettant un examen plus approfondi de ces sections de code.

Les langages varient dans leur degré de sécurité de la mémoire institué par des protections et des atténuations inhérentes. Certains langages n'offrent qu'une sécurité de mémoire relativement minimale alors que certains langages sont très stricts et offrent des protections considérables en contrôlant la manière dont la mémoire est allouée, accessible et gérée. Pour les langages avec un niveau extrême de protection inhérente, un travail considérable peut être nécessaire pour obtenir simplement le programme à compiler en raison des vérifications et des protections.

La sécurité de la mémoire peut être coûteuse en matière de performances et de flexibilité. La plupart des langages mémoire sécurisés nécessitent une sorte de récupération de place pour récupérer la mémoire qui a été allouée, mais qui n'est plus nécessaire au programme. Il existe également une surcharge de performances considérable associée à la vérification des limites de chaque accès à la baie qui pourrait potentiellement se trouver en dehors de la baie.

Alternativement, un impact similaire sur les performances peut exister dans un langage non sécurisé en mémoire en raison des vérifications qu'un développeur ajoute au programme pour effectuer la vérification des limites et d'autres protections de gestion de la mémoire. Les coûts supplémentaires liés à l'utilisation de langages non sécurisés pour la mémoire incluent une corruption de mémoire difficile à diagnostiquer et des plantages occasionnels des programmes ainsi que de potentielles exploitations des vulnérabilités d'accès à la mémoire. Il n'est pas anodin de faire passer une infrastructure de développement logiciel mature d'un langage informatique à un autre. Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage.

Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera.

Source : NSA

Et vous ?

Que pensez-vous des conseils de la NSA ? Y en a-t-il que vous appliquez déjà ?
Que pensez-vous du fait que l'agence préconise l'utilisation des langages de programmation sécurisés pour la mémoire comme C#, Go, Java, Ruby, Rust et Swift ?
« Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage. Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera ». Qu'en pensez-vous ? Êtes-vous d'accord avec l'agence ?

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

Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 23/01/2023 à 20:46
Citation Envoyé par Padget Voir le message
je dirais que le c++ est tout autant sécurisé que rust. pour ce qui est de la mémoire il y a les smart pointers dans les deux langages : unique_ptr et Box. Le cpp offre autant que le rust la gestion du cycle de vie des objets.
Pour la gestion de la mémoire, le C++ offre la possibilité d'utiliser le RAII qui évite les double free et permet aux éventuelles fuites de mémoire de ne pas être plus fréquentes que dans un langage avec ramasse-miettes.

Il y a des développeurs C++ qui sous-utilisent le RAII et introduisent plein de fuites de mémoire, ce qui est un problème culturel autour de l'apprentissage du C++.

Cependant, le C++ n'empêche pas à la compilation les dandling references/pointers/iterators. Par exemple, si on garde une référence vers un élément d'un vecteur, puis que l'on fait un push_back, que ce dernier oblige de déplacer ailleurs en mémoire les éléments du vecteur, puis que l'on essaie d'accéder à ce vers quoi pointe la dandling reference, cela ne provoque pas d'erreur de compilation, contrairement à Rust. Le C++ n'a pas autant de contrôles à la compilation qu'en Rust.

Idem pour le multithreading : le C++ ne fait pas de contrôle à la compilation contre les accès concurrents.

Le C++ n'a pas le borrow checker de Rust. Pour les contrôles à la compilation, ces deux langages ne sont clairement pas au même niveau.
9  0 
Avatar de thamn
Membre averti https://www.developpez.com
Le 23/01/2023 à 22:23
Hebe, il va pas bien Bjarne ou quoi? Il a oublie que C++ a besoin des sanitizers pour ne meme pas arriver au niveau du borrow checker de rust?
Bon, il defend son bout de pain apres, il perd pas le nord, mais bon de la a dire des trucs pareil je sais pas trop..
8  1 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 08/12/2023 à 10:47
La comparaison de Rust face à C++ m'a toujours paru assez fallacieuse :
Je la vois toujours évoqué sans tenir compte de l'écosystème du développeur, à croire que ces 2 langages sont comparés nus.

Comparer un langage qui tire parti d'un complément de fonctionnalités par des outils externes, à un autre qui en incorpore certaines en natif, mais le faire sans ces dit outils a-t-il du sens ?

Dans un second temps, Bjarne Stroustrup rappelait à l'occasion de la cppCon 2023 (billet dvp.com du 6 octobre ici) que la question de la sécurité (et la sûreté) n'a pas démarré il y a quelques années, et que les principales règles de codage qui gouverne la sécurité par le code existent depuis au minimum les années 90.
Depuis cette époque la problématique n'a pas changé --> le difficulté n°1 est de trouver une solution pour que la masse des développeurs aient connaissance de ces règles, la difficulté n°2, qu'ils finissent par avoir l'habitude de les appliquer.
La difficulté n°2 vient du fait que l'on code avant tout pour répondre à un besoin pratique, et que parmi tous les aspects à traiter sur les concepts à choisir et leur implémentation, les développeurs finissent par oublier d'appliquer certaines notions de sécurité. En découle des erreurs types, comme :
Les erreurs de logique - où ce qui est écrit s'écarte de la manière dont le codeur le pensait (ex : utiliser '<' là où '>' était pensé)
les fuites de ressources
les erreurs de concurrence
les erreurs de typage
les overflow et les conversions implicites
les erreurs de timing - ex : coder un retour à 1,2 ms à un périphérique qui répond aux évènements externe en 1 ms max
les allocations non prédictibles
les erreurs d'arrêt -

NB : pour les diapos de la conférence : lien_github
NB : pour la conférence :


Il rappel également que bien qu'une alternative soit "memory safety", ce n'est pas suffisant, la sécurité doit être traité globalement, sur tous ses aspects.
Une question revient alors assez souvent : si Rust permet plus facilement de produire du code "memory safety" pour une plus grande part de développeurs, Rust permet-il d'atteindre un plus haut degré final de sécurité ?
Que la réponse soit "oui" ou "non", Rust permet-il à un plus grand nombre de développeurs de produire du code plus sûr ?
A cette dernière question, je pense pouvoir dire "oui", car permet de le faire de manière plus accessible tous niveaux de maîtrise confondu.

Une chose est sûr : l'aspect déterministe du code produit en Rust semble être l'un des atouts majeur en terme de garantie sur la sécurité du code produit et son analyse.
Mais je constate aussi que beaucoup de code produit sont lourd à l'exécution (mémoire, CPU...) parce que le code n'est pas suffisamment verbeux (explicitement écrit).
Un exemple flagrant, lors d'une démonstration par Jason Turner à la cppCon 2016, où après avoir fait un mapping des couleurs, il faisait face à un overhead.
Une simple transformation de " static std::array<Color, 16> colors {{... " en " static const std::array<Color, 16> colors {{... " et ses 354 instructions d'assembleur se transforment tout à coup en 7 instructions.
La conférence cppCon 2016 : lien_youtube
5  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 24/01/2023 à 12:22
Bjarne Stroustrup est sans conteste un immense contributeur au monde du développement informatique, mais il défend son bébé qui... conserve ses défauts.

J'ai commencé l'informatique avec C++, touché à bien des langages, et je reconnais les qualités de Rust malgré ses défauts comme le temps de compilation et le manque de lib. Pour moi Rust est un pas en avant, il est ce que C++ a essayé d'être si C++ n'avait pas essayé de rester rétro-compatible avec C dans un premier temps, puis avec lui-même. Je vois les efforts de Herb Sutter, il essaye d'améliorer C++ avec "CppFront" mais même avec ça on n'arrive pas au niveau des exigences de Rust en terme de null-safe, memory-safe, thread-safe
5  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/01/2023 à 12:32
C'est a rapprocher du récent document de Bjarne Stroustrup en tant que membre du groupe de direction de l'ISO C++ : https://www.open-std.org/jtc1/sc22/w...23/p2759r0.pdf

On voit bien qu'il est pris de court par le tournant actuel de l'industrie vers une sécurisation par défaut, qu'il n'a pas du tout anticipé, et dont il a encore du mal à admettre l'importance. On voit qu'il a tendance à réduire le problème au fait que le C++ devrait mieux communiquer sur ses fonctionnalité de sécurité. Il peine à cerner ce qu'est exactement Rust et ce qu'il apporte(approximations, exemples mal choisis, ...). Après avoir passé une grande partie du document a minimiser le problème, il ébauche quand même un chemin vers une vraie sécurisation du C++, mais on voit bien qu'ils sont encore loin ne serait-ce que d'un embryon de solution consensuelle.
4  1 
Avatar de vivid
Membre régulier https://www.developpez.com
Le 25/11/2022 à 9:09
"Plus de 20 ans que j'avertis mes étudiants des risques liés à la gestion mémoire par C et que je les pousse à la POO et plus particulièrement à Java "

un bon nivellement par le bas, bravo
2  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 08/12/2023 à 13:40
Citation Envoyé par Regulus136 Voir le message
En fait il faut expérimenter ce langage incroyablement verbeux pour comprendre sa douleur.
Je peux comprendre que Rust soit qualifié de verbeux par rapport à du Python. Mais, qualifier Rust d'"incroyablement verbeux" par rapport à C++, cela m'étonne. Il y a des choses plus concises en C++ et d'autres plus concises en Rust. Aurais-tu un exemple de code "incroyablement verbeux" en Rust sous la main à partager ?
3  1 
Avatar de seedbarrett
Membre éclairé https://www.developpez.com
Le 08/12/2023 à 14:31
Les agences Five Eyes insistent pour que les organisations abandonnent C++ pour le langage Rust
Quand je lis ça, j'ai plutôt envie de rester sur C++
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 11/12/2023 à 16:38
Citation Envoyé par Steinvikel Voir le message
La comparaison de Rust face à C++ m'a toujours paru assez fallacieuse :
Je la vois toujours évoqué sans tenir compte de l'écosystème du développeur, à croire que ces 2 langages sont comparés nus.
Les deux comparaisons peuvent avoir un sens, il s'agit juste de savoir de quoi on parle.
Bien sur qu'un langage comme Rust n'a pas encore tout l'écosystème de bibliothèques et d'outils qui ont été développé pour C++ pendant plusieurs dizaines d'années, ceci dit c'est un problème qui a déjà bien commencé à se résorber. Si on veut un langage a utiliser immédiatement, c'est bien évidement à prendre en compte au moment du choix.

Ca ne veut pas dire pour autant qu'il n'y a pas d’intérêt à analyser les capacités intrinsèques d'un langage pour savoir ce qu'il permet déjà de faire techniquement, même si les bibliothèques restent a coder, et ce qu'il ne permettra pas de faire, peu importe ce que l'on code.

Citation Envoyé par Steinvikel Voir le message
Comparer un langage qui tire parti d'un complément de fonctionnalités par des outils externes, à un autre qui en incorpore certaines en natif, mais le faire sans ces dit outils a-t-il du sens ?
Il faudrait préciser ce que tu entends par là car Rust comme C++ sont relativement indépendant d'outils externes, pour le fonctionnement de base des langages au moins.

Citation Envoyé par Steinvikel Voir le message
Dans un second temps, Bjarne Stroustrup rappelait à l'occasion de la cppCon 2023 (billet dvp.com du 6 octobre ici) que la question de la sécurité (et la sûreté) n'a pas démarré il y a quelques années, et que les principales règles de codage qui gouverne la sécurité par le code existent depuis au minimum les années 90.
Depuis cette époque la problématique n'a pas changé --> le difficulté n°1 est de trouver une solution pour que la masse des développeurs aient connaissance de ces règles, la difficulté n°2, qu'ils finissent par avoir l'habitude de les appliquer.
La difficulté n°2 vient du fait que l'on code avant tout pour répondre à un besoin pratique, et que parmi tous les aspects à traiter sur les concepts à choisir et leur implémentation, les développeurs finissent par oublier d'appliquer certaines notions de sécurité.
Si c'est vrai que comme le dit Stroustrup dans sa conférence, la sécurité du C++ a évolué tout au long de son histoire, ça a quand même été, pendant très longtemps, une préoccupation secondaire bien derrière la performance et la compatibilité. Il y avait certes de bonnes raisons de faire ce choix, mais, l'état actuel du C++ au niveau de la sécurité en est clairement la conséquence. Bjarne Stroustrup ne se penche sérieusement sur la sécurité du C++ que depuis qu'il y est poussé par l'arrivée des langages de bas niveau alternatifs et par les autorités de sureté.

Là ou il me parait très lucide dans sa conférence, c'est quand il dit clairement : "Being careful does not scale" (Être prudent n'est pas tenable à grande échelle). Ca change des discours qu'on peut entendre encore bien trop souvent sur le C et le C++. Par contre, une bonne partie de son discours ressemble pas mal à du déni des problèmes. En même temps c'est dur de lui reprocher de défendre son bébé. Quand il dit qu'il n'y a pas que la sécurité mémoire à prendre en compte, c'est vrai, mais c'est quand même de l'ordre des 2/3 des vulnérabilités critiques dans la plupart des grosse bases de code C++, y compris celles moderne et surveillées. Et pour les autres type de problème de sécurité qu'il évoque, le C++ est là encore à la traine comparé a ses alternatives modernes.

Citation Envoyé par Steinvikel Voir le message
Mais je constate aussi que beaucoup de code produit sont lourd à l'exécution (mémoire, CPU...) parce que le code n'est pas suffisamment verbeux (explicitement écrit).
Un exemple flagrant, lors d'une démonstration par Jason Turner à la cppCon 2016, où après avoir fait un mapping des couleurs, il faisait face à un overhead.
C'est le coté potentiellement surprenant des optimisations, mais pour le coup ce genre de chose peut tout aussi bien arriver en C++ qu'en Rust
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 14/12/2023 à 3:29
Citation Envoyé par mintho carmo Voir le message
Je suis d'accord que le comité n'a pas explicitement déprécier beaucoup de syntaxes, pour autant, je suis pas d'accord avec le "pas facilement identifiables". Les problèmes de sécurité du code et les bonnes pratiques sont des choses qui sont largement documenté depuis plus de 20 ans, dans des livres, des blogs, des talks, etc.
Les bonne pratiques ça clairement ces limites. Tu as des gens plus ou moins formés, avec une pratique plus ou moins avancée. Malgré une formation, on peut facilement avoir de mauvaises conceptions. Par exemple, contrairement à ce que tu disais, il ne suffit pas d'utiliser vector ou string : il faut aussi faire attention à comment on les utilise. Je suppose que tu étais bien au courant et que tu as expliqué ça de manière un trop simplifiée, mais c'est typiquement le genre de soucis qui va arriver, que ça soir par mauvaise compréhension du concept ou inattention à l'utilisation.
Les usages à risques sont plus difficile a voir dans la pratique que dans les exemple de cours. Même les experts, à jour, et qui pratiquent en permanence, finissent fatalement par faire des erreurs car les fonctionnalités problématique sont trop facilement accessible par inadvertance.

Le fait que le compilateur te refuses simplement les usages à risque change complètement la donne.

Citation Envoyé par mintho carmo Voir le message

Les raisons que j'ai entendu le plus souvent pour la non utilisation des "bonnes pratiques", c'est pas "je savais pas que ca existait", mais :
- "ca marche bien comme ca, avec mon vieux code" (non, tu teste comme un singe et c'est pour ca que tu vois pas les bugs)
- "je dois maintenir du code legacy" (ca n'empêche pas de faire évoluer le code et c'est aussi ton boulot d'expert d'expliquer aux décideurs le cout de maintenir le code legacy plutôt que le faire évoluer)
- "pas le temps de me former" (et c'est pour ça que tu es obsolète et que ton code est mauvais)
- etc
C'est la dure loi de la réalité et on ne peut pas faire comme si ça n'existait pas.
C'est une bonne partie de la raison pour laquelle le fait que le langage ne tolère pas de cacher facilement la merde sous le tapis est utile.

Citation Envoyé par mintho carmo Voir le message
Mais, dans la même idée, les erreurs évitables par Rust sont qu'une (petite) partie des bugs que l'on retrouve sur les applications. Quand on regarde par exemple la publication des vulnérabilités sur OpenSSL, c'est beaucoup des erreurs de logique, des choses qui ne sont pas détectables par Rust ou des sanitizers. Je pense que c'est dans ce sens que Stroustrup parlait de sécurité globale. Je suis juste pas du tout convaincu, pour le moment, que l'utilisation de Rust aura un impact significatif sur mon travail de tous les jours et la qualité de mes codes.
J'ai regardé vite fait les CVE d'OpenSLL de cette année. C'est environ 40% de toutes les CVE qui sont dues à gestion mémoire, ça monte à 60% si regarde les CVE de sévérité moyenne ou plus. C'est globalement ce qu'on constate sur la plupart des projets C++ conséquents : environ les deux tiers des vulnérabilités importantes sont liées à des problèmes de sécurité mémoire.

Citation Envoyé par mintho carmo Voir le message
Il n'y a justement pas besoin de quoi que ce soit de la part du comité. C'est juste une question de choix de la part des devs de ne plus utiliser certaines syntaxes, certains idioms, suivre certaines pratiques, sans qu'il soit nécessaire de déprécier quoi que ce soit.
Sauf que la pratique a démontré que ça ne marche pas. C'est ce qu'entent Biarne Stroustrup quand il dit "Being careful does not scale". Sur un code suffisamment compliqué il y aura forcément une mauvaises utilisations involontaires si on ne met pas en place des garde-fous.
2  0