Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Il y a 10 ans, le C++ fut mon premier langage, il a beau avoir des features intéressants aujourd'hui mais il n'en reste pas moins un langage complexe à cause de sa richesse syntaxique. Si je devais utiliser un langage pour un projet qui possède des contraintes, je me pencherais surement vers du C même si je reconnais que ce dernier a ses défauts, voire Golang si possible.
N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java
Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ?Contacter Gokan EKINCI
Oui parce que c'est bien le langage qui est mit en cause dans le sujet.Envoyé par koyosama
En théorie, oui.
On peut effectivement avoir des applis de très bonne qualité à tout points de vue, fait avec un langage que l'on pourrait considérer inadapté....et aussi l'inverse.
L'humain et la méthodologie, restent les facteurs essentiels.
Mais quand même, les fonctionnalités récentes apportées par certains langages comme C++11 et 17 facilitent grandement la vie.
L'expert en sécurité Mozilla donne son avis... perso je trouve que ça donne un peu l'impression qu'il découvre l'eau tiède.
C'est pas nouveau cette critique des langages "unsafe", et les langages censés régler ce problèmes sont apparus bien avant Rust ou Swift. Sauf que si on regarde le top 10 de l'OWASP, ben y'a rien de spécifique à C/C++. Au contraire même: les tonnes d'attaques et scripts malicieux qui rendent Interne dangereux ciblent des stack logicielles supposées "safe".
Mais surtout, je ne suis pas sur que Mozilla soit le mieux placé pour donner des leçons sur l'engagement des développeurs C/C++. Car Mozilla, malgré son utilisation intensive de ces langages, malgré sa forte dépendance aux outils et libs open source C/C++, ben c'est le grand absent de cette communauté. Et ça date pas de leurs débuts avec Rust. Que ce soient le comité de normalisation, le développement des outils, compilateurs, checker, ou plus simplement la participation aux conférences C++ : ils sont invisibles (sauf pour vendre WebAssembly). Contrairement aux autres grands acteur du web, à qui on doit une grande partie des avancées considérables effectuées ces 10 dernières années en C++. Alors peut etre qu'il devrait commencer par balayer devant sa porte. Parce que s'il faisait l'effort d'aller au contact de la communauté, il verrait que les développeurs ne se fichent pas du tout, mais alors pas du tout de la qualité de leur code. Faut quand mème rappeler que le modèle sémantique qui a influencé Rust (RAII, move semantic, ownership fort) provient directement des travaux menés en C++!
Et en ce qui concerne HeartBleed, cette faille a surtout révélé le peu de moyens à dispo pour maintenir cette lib critique pour Internet. Elle aurait pu être découverte en quelques minutes en exécutant les outils d'analyse à dispo déjà à l'époque, mais faute de moyen, on connaît la suite. Et utiliser un binding OpenSSL en Swift ou Rust, ça va pas changer grand chose au problème. Et oui : la sécurité c'est pas juste une histoire de développeurs, mais de moyens et priorités donnés par le management. Certains grands acteurs du Web ont en tiré les leçons et on investi sur le maintient de cette bibliothèque. A ma connaissance, Mozilla n'a rien fait. Alors qui se fiche le plus de la sécurité du web ?
C'est pas en théorisant depuis sa chambre sur ce que devraient ou ne devraient pas faire les gens qu'on fait avancer les choses, mais en montrant l'exemple à suivre. Exemple très récent :
Sinon, on s'écoute juste parler. Et certaines personnes telles que Torvalds ont des avis bien tranchés sur ces experts en sécurité qui débarquent avec leurs grandes leçons : "Those security people are f*cking morons".
Il y a moyen d'avoir un lien vers la liste précise ? J'ai regardé le wiki mais c'est un peu le bazar.
Les langages "safe" prennent progressivement leur PdM. Et d'autre part, une différence majeure entre les langages safe précédents et Rust, est que Rust n'a pas cherché à cacher la complexité inhérente des systèmes qu'on design avec C ou C++, il a rendu obligatoire le traitement des propriétés de safety. Et c'est avant tout ça le problème pour la sécu sur C ou C++ : il faut montrer que ces propriétés de safety sont respectées, mais c'est rarement fait.
En même temps ici, c'est pas vraiment Mozilla qui parle, c'est Alex Gaynor qui est ingénieur en sécurité*. Bref, pas un décideur de chez Mozilla, et pas un type qui était chez eux avant leurs débuts avec Rust.
*(d'ailleurs la seule mention à Mozilla dans l'article sur DVP c'est pour dire ce qu'il y bosse, et il y bosse depuis 2017. Et dans l'article original, il y a 3 mentions : une pour dire qu'il y bosse, une pour dire que l'avis sur Rust est potentiellement biaisé parce que le mec est de chez Mozilla, et la dernière pour dire où Rust est utilisé et il y a - ofc - Mozilla dans la liste)
Alors il faut rendre à César ce qui est à César. Le RAII et le move, ça vient effectivement de C++, mais clairement c'est complètement insuffisant pour assurer la memory safety.
Le modèle d'ownership de Rust est lié aux fractional permissions qui sont des travaux de Boyland (2003) utilisés pour vérifier du code en présence d'alias. C'est une généralisation du comptage de références qui était étudié surtout pour les garbage collectors, c'est apparu assez tard dans C++ (même si on compte Boost) par rapport aux premiers GC basés sur le reference counting. Le modèle de fractional permissions de Rust est plus général que celles de Boyland, et il est lié à des travaux plus récents qui permettent leur adaptation à du code concurrent. Bref, les notions de "owner" ne sont pas les mêmes en Rust et en C++.
Le vrai apport de Rust c'est son utilisation des linear types pour apporter les garanties manquante du RAII et dans le même temps la vérification des fractional permissions dans le typeur du langage y compris dans un context concurrent. En l'occurrence, ce n'est pas à la portée de ce qu'on sait faire dans le typeur C++ et ça donne beaucoup plus de garanties. En plus avec les suppositions qu'on gagne au passage, on peut raisonner de manière bien plus facile sur les programmes qui typent.
Dans mon labo, lors de la découverte de HeartBleed, on avait fait des tests avec nos outils (formels) et avec d'autres outils (non formels), les outils non formels passaient à côté, et les outils formels donnaient simplement trop d'alarmes. Que ce soit pour une classe d'outil ou l'autre, il fallait tweaker précisément les configurations pour exhiber la faille, et c'est pas très réaliste : quand on on sait ce qu'on cherche, on le trouve. Aujourd'hui, on y arriverait probablement avec les outils formels et informels, mais en grand partie parce qu'HeartBleed a fait office d'électro-choc, et que le financement des projets liés à la sécu a augmenté.
On peut pas dire que développer un nouveau langage safe by design ce soit ne rien faire (et je pense que ça a plus de chances d'aboutir à quelque chose de robuste que continuer à faire grossir/patcher des langages qui sont unsafe par nature). Par ailleurs, Mozilla finance de la recherche sur la sécurité. Ou encore intègre des composants de sécurité provenant de la recherche comme HACL*. En l'occurrence, HACL*, ça fait partie du Project Everest qui vise à développer des stacks logicielles correctes et formellement vérifiées, par exemple pour remplacer OpenSSL. Parce que non, vérifier formellement OpenSSL c'est clairement hors de portée de tous les outils aujourd'hui. Par contre générer du code correct et efficace, on sait faire.
Pour le coup, je pense que cette vidéo confirme juste parfaitement ce que Gaynor met en exergue. En particulier le tout début de la présentation, lorsqu'il demande à l'audience qui met en place divers moyen de s'assurer de la sécurité de ses softs et que le résultat c'est : "Ok, some, usually most of people don't". C'est super parlant sur la situation. C'est même vachement plus pessimiste que je ne le pensais, et pourtant j'ai tendance à être super pessimiste sur la question.
C'est marrant de mettre de parler de "s'écouter parler" et après de citer Linus qui est quand même bien connu pour avoir un avis tranché sur plein de trucs mais rarement le bon, en particulier parce que son argument favori, ça reste l'argument d'autorité. On parlait plus haut de management, on parle quand même d'un type qui est incapable de bosser avec les autres.
D'autres part les "security people", ils ont pas attendu l'avis de Linus pour faire des trucs bien plus blindés que la moyenne, seL4 pour ne citer que lui, ou HACL* cité plus haut.
Il n'y a pas de GC dans Rust. Et la présence d'un GC n'est pas nécessairement gage de pertes de performances, en particulier si tu as un mécanisme qui permet de tweaker le GC pour ton problème précis, dans ce cas, tu peux même arriver à obtenir de meilleurs performances pour un coût de développement moindre.
Bien sûr, on peut écrire du code C correct qui ne contient pas de bugs. Mais ça demande d'y mettre beaucoup de moyens, bien au delà de ce qui est généralement fait. Et c'est à cause du langage. Si vérifier du C, c'est super dur, c'est parce qu'il est ultra permissif et que sa norme est imprécise et difficile à comprendre.
Avec les mots clés "OWASP Top Ten" tu trouves des listes plus ou moins détaillées:
https://www.owasp.org/index.php/Top_10-2017_Top_10
On trouve aussi des comparatifs avec les changements d'une certaine année à une autre:
https://www.advens.fr/fr/ressources/...-notre-analyse
Je faisais référence au fuzzing couplé à une compilation en mode "analyse & détection de problèmes" tel que ASan. Cette technique a été testé avec succès 1 an après la découverte de la faille:
https://blog.hboeck.de/archives/868-...een-found.html
sans "tricher" en ciblant la fonction incriminée, il faut quelques heures pour détecter les premiers problèmes. Avec des tests plus ciblés, il ne faut que quelques minutes.
Voici une article assez complet qui traite de nombreux aspects, y compris la pertinence de C/C++ dans le développement :
https://dwheeler.com/essays/heartbleed.html
c'est d'un tout autre niveau que ce qui a été raconté par notre expert en "click bait'
J'ai été très irrité (et un peu brutal) dans mon post car très agacé de tomber sur cet article via Google News avec un titre qui non seulement rend C/C++ responsable des principaux dangers sur Internet, mais en plus sous entend que c'est la faute aux développeurs qui s'en fichent. Non mais WTF?
Ce n'est pas tant ce qu'il dit que je trouve lamentable, mais les conclusions qu'il se permet de tirer. Et j'ai donné la vidéo pour montrer la différence entre quelqu'un qui théorise dans son coin sur comment devraient être le monde, et quelqu'un qui agit à la source du problème en montrant comment le régler.
Ensuite, si je fais un tour rapide sur les failles critiques du moment:
https://www.cvedetails.com/vulnerabi...abilities.html
les technos concernées sont:
- Javascript
- PHP
- Python
- Electron (JS)
- Shell
- C (firmware)
- Erlang
En quoi recoder les applis C++ en Rust ou Swift va changer quoi que ce soit à cette liste ?
Et si je regarde sa liste d'exemples sur les dangers causés par C/C++ pour Internet :
- WanaCry: un ransomware qui se propage via une faille du protocole SMB, donc réseau local Windows
- HeartBleed: ça a forcé la mise à jour de beaucoup de serveurs... et puis pas grand chose d'autre
- son 3eme exemple: un article sur la vente de failles zero day de 1.5 à 3 millions d'euros : autant dire que c'est pas pour cibler Madame Michu
Par contre, Madame Michu fait partie des 90 millions de comptes concernés par la faille FaceBook d'il y a 3 semaines, c'est bien elle qui se fait piéger par des pages de phishing hébergées sur des sites Wordpress (ou autre) compromis, et c'est bien son PC et son téléphone qui chauffe du CPU pour miner du bitcoin via un script JS malicieux injecté, etc, etc...
Si certaines failles en C/C++ ont un fort retentissement médiatique, c'est parce que beaucoup d'applis qui propulsent Internet sont en C/C++ : du code embarqué des routeurs aux navigateurs, en passant par les OS, bases de données, compilateurs (Swift en particulier...), interpréteurs, décodeurs vidéos et j'en passe: sans C/C++ il n'y a pas d'Internet (ni de Python, Php, JavaScript, ...). Derrière le moindre script Php qui affiche "Hello Word" il y a des centaines de millions de LOC en C/C++. L'écrasante majorité des failles sur Internet se produisent dans les quelques milliers de lignes en haut de cette pile, écrites dans des langages "memory safe". Mais lui il va à la pêche aux bugs (qui ne sont pas nécessairement des failles) dans les projets qui comptent des dizaines de millions de LOC (Android, Chrome, FireFox...).
Sa conclusion : Internet est en danger à cause de C/C++, alors même que des centaines de millions de sites sont protégés et sécurisés par des serveurs écrits dans ces langages. Son conseil : "recodez tout en Swift ou Rust pour évitez cette dizaine de bugs rencontrés sur une année dans votre application de 20M LOC". Étrangement les développeurs haussent les épaules...
Le pire dans tout ça c'est qu'il y a réellement un vrai problème et un vrai danger relatif à C/C++ et Internet : au niveau des objets connectés. Et là y'a un vrai travail de fond à mener. Mais en y regardant de plus près, c'est (sans surprise) pas tant un problème technique qu'une question de priorités business (objets connectés low cost...).
Car si on prend une équipe de développeurs C/C++ qui se fiche de la sécurité et qu'on les fait basculer sur le langage magique X, on obtient une équipe de développeurs X qui se fichent toujours de la sécurité. C'est pour ça qu'on embauche des experts en sécurité, et c'est pour ça que je suis remonté contre ce monsieur car c'est son job d'éduquer et d'accompagner son entreprise (développeurs, mais aussi et surtout le management) en montrant comment faire mieux. S'il n'est pas écouté, s'il ne parvient pas à avoir un impact, qu'il se questionne un peu sur comment il s'y prend.
Car je pourrais pousser un peu la provoc en disant qu'il contribue à dégrader la situation de part son ignorance des dynamiques humaines / réalités économiques. Quand une entreprise a investi plusieurs millions d'euros dans un logiciel, et qu'elle commande un audit pour le moderniser, si on lui dit "oh là il faut tout recoder en <langage hype du moment>", alors merci c'est gentil mais non, c'est trop cher. Donc on fait rien, et on laisse dépérir tous les jours un peu plus. Mais si on lui propose un plan de modernisation (via des outils de réécriture automatisée tel clang-tidy) et de mise à niveau sécuritaire (analyseurs statique et dynamique de code) qui lui permettent de préserver son patrimoine logiciel pour un coût nettement moindre, alors elle signera! Ces outils on les a en C++ (certains coutent un peu cher) et ils font leurs preuves sur des bases de code de plus de 50M LOC. Mais il faut avouer que les profils capables de gérer ces chantiers sont rares... On retombe sur la problématique de l'humain.
A condition de disposer de plus de mémoire (3 à 6 fois plus pour bien tourner). A noter qu'il est aussi possible de tweaker sa gestion mémoire en C++ pour (grandement) accélérer les performances là où c'est nécessaire (les développeurs de jeux vidéos maitrisent bien ce sujet). A ce propos on dit que C++ ne donne pas automagiquement de la performance, C++ donne accès à la performance.
Thanks.
Un an après, je le classerais dans le sursaut HeartBleed. Tu cites par exemple ASan, mais il est apparu juste deux mois avant qu'HeartBleed sorte des cartons publiquement. Et je me souviens qu'à ce moment là, l'adresse sanitizing c'était pas encore quelque chose de vraiment commun auprès des développeurs.
Je ne pense pas qu'on puisse éjecter si facilement l'unsafety des langages de la source. Vérifier du C ou du C++ à un niveau très élevé c'est tellement coûteux que presque aucune boîte ne peut se le permettre. Les seuls codes C vraiment blindés que je connaisse sont dans les domaines critiques (nucléaire, ferroviaire, aéronautique, armement) ou dans la recherche (seL4, VerisoftXT).
Erlang dans la liste, j'avoue que je m'attendais pas à le trouver là. Mais sinon pour les technos JS et PHP j'aurai bien une réponse : il faut les réécrire aussi. Pour Python, je pense qu'on pourrait faire un parallèle avec l'évolution de son adoption pour des nouveaux projets.
Ici, il y a plusieurs aspects.
Déjà, beaucoup de langages memory-safe parmi ceux utilisés sont anciens et à peu près aussi mal foutus que C ou C++ sur bien des aspects : notamment un passif super lourd avec pas mal d'itérations de patchs sur des éléments obscurs du langage, voir sont carrément du genre à faire des croche-pied au développeur à coups de comportements définis mais bizarres (PHP ou JS par exemple). Et de ce côté, d'autres langages avec un design plus clean veulent aussi reprendre le flambeau (Nim, Swift, ... même si je pense qu'on est loin du design d'un Rust).
Ensuite, prétendre qu'il n'y a pas beaucoup de contenu en terme de ligne de code en sommet de pile, c'est fort de café. Ces langages sont aussi très utilisés pour le développement de bibliothèques et de framework pour leurs propres usages. S'ajoute à cela que ces éléments embarquent parfois aussi du code C ou C++, et qu'on risque d'y trouver des problèmes aussi.
Par ailleurs, et c'est à mon sens le plus important, développer une implémentation de langage dans un langage aussi complexe que C ou C++, c'est aussi se mettre des bâtons dans les roues. On sait que ces codes sources sont super difficiles à vérifier et à comprendre dans leur vision haut niveau. Donc effectivement, ça va être difficile de savoir si le truc qu'on a implémenté par dessus est correct et qu'on a pas fait de connerie en produisant l'implémentation de notre langage safe.
Il y a très clairement des problèmes qui sont purement techniques et qui font qu'il est très complexe de dire que l'on va faire une sélection par criticité par exemple. Je suis impliqué dans un projet de recherche qui vise à améliorer la sécu dans ces dispositifs. Et d'office, il y a un problème de taille : la plupart des périphériques ciblés n'ont même pas de séparation user-space/kernel-space au niveau matériel parce que c'est trop coûteux en énergie. Résultat : tout est critique depuis l'OS jusqu'aux éléments qui tournent dessus et qui réalisent les tâches à la con. Le tout écrit en environnement contraint, donc avec comme premier critère l'optimisation de l'espace et de la performance, parce que sinon le device tournera même pas, donc la sécu c'est secondaire, il faut déjà que ça tourne tout court.
Donc c'est un peu chaud de reprocher aux décideurs de ne pas vouloir investir un budget qu'on investit même pas dans du soft qui n'a pas ces contraintes.
Sauf que selon le langage X sur lesquels tu les fais basculer, tu changes radicalement leur potentiel de nuisance quand même. Quand leur seule manière d'avoir toute une classe de faille de sécurité dans leur code (les UB du C typiquement), c'est de se coller volontairement une balle dans le pied en écrivant volontairement "UNSAFE" un peu partout dans leur code, ben ils savent qu'ils sabotent volontairement leur système. Là où en C, c'est facile de faire un truc fortuit et dur à détecter même avec des bons outils.
S'ajoute à cela que quand ton langage te donne toute une classe de garanties par construction, c'est autant de classes de vulnérabilités dont tu n'as pas à te préoccuper dans tes outils d'analyses supplémentaires et donc tes outils d'analyse sont plus simples et tu peux focaliser tes efforts sur des propriétés plus intéressantes qui apportent des garanties plus fortes, etc.
En revanche, comme je le disais plus tôt, le problème c'est que pour l'instant, ces outils supplémentaire ne sont pas encore au niveau de ce qui se fait en C++ ou en C dans les nouveaux langages qui apparaissent. Mais ça veut quand même dire que toute une classe de développeur peut déjà migrer sans perdre dans le cas du développement d'un nouveau projet.
Finalement, dans le monde open-source, il est pleinement justifié que certains prennent la peine de redévelopper des éléments existant de notre stack avec des technos plus safe, et il faut que ça continue. C'est trop dur de s'assurer que du soft qui grossit perpétuellement est correct.
Tu peux avoir une memory-footprint fitted à la centaine de Mo près dans un système qui run sur des Go de RAM.
C'est beaucoup moins vrai quand les programmeurs adhère au modèle SOLID.
Memory safe
Le probleme avec les langages memory safe c'est que c'est souvent pas optimisé du tout faisant intervenir du garbage collector...
Je pense que la premiere critique doit être fait a l'OS et aux dev. La faute aussi au C mais pas aussi grande que les dev
Répondre avec citation
Partager