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

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

  1. #21
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 544
    Points
    544
    Par défaut
    Ça reste hors de portée d'une formalisation. Sans compter que les fonctionnalités qui sont en cours de discussion pour C++20, c'est pas des enfants de chœur.

  2. #22
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 579
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 579
    Points : 17 834
    Points
    17 834
    Par défaut
    La copîe d'écran montre un appel avec memset or maintenant on évite cette instruction il y a une instruction sécurisée comme memset_s.

    En compilant avec Visual Studio C++ on obtient des warnings si on utilise cette instruction.

    Ensuite plus on utilise des instructions du C/C++ non sécurisé plus il y a de chances pour que l'exécutable soit détecté comme un faux positif par les anti-virus

  3. #23
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 309
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 309
    Points : 3 646
    Points
    3 646
    Billets dans le blog
    12
    Par défaut
    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

  4. #24
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    juin 2003
    Messages
    5 735
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 735
    Points : 10 560
    Points
    10 560
    Billets dans le blog
    3
    Par défaut
    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".

  5. #25
    Candidat au Club
    Homme Profil pro
    Etudiant
    Inscrit en
    juillet 2017
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Etudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : juillet 2017
    Messages : 5
    Points : 4
    Points
    4
    Par défaut 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

  6. #26
    Membre confirmé
    Homme Profil pro
    Développeur multiplateformes
    Inscrit en
    mars 2003
    Messages
    263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Développeur multiplateformes
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2003
    Messages : 263
    Points : 591
    Points
    591
    Par défaut
    Citation Envoyé par koyosama Voir le message
    Je ne comprends pas les gars, vous parler tous du language en lui-meme,
    Oui parce que c'est bien le langage qui est mit en cause dans le sujet.

    Citation Envoyé par koyosama Voir le message
    vous pouvez le faire en assembleur, cela change rien a la maintenance.
    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.

  7. #27
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 544
    Points
    544
    Par défaut
    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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".
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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..
    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)

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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++!
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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.
    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é.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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 ?
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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 : video
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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".
    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.

    Citation Envoyé par bewwys Voir le message
    Le probleme avec les langages memory safe c'est que c'est souvent pas optimisé du tout faisant intervenir du garbage collector...
    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.

    Citation Envoyé par bewwys Voir le message
    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
    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.

  8. #28
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    juin 2003
    Messages
    5 735
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 735
    Points : 10 560
    Points
    10 560
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par KsassPeuk Voir le message
    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.
    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

    Citation Envoyé par KsassPeuk Voir le message
    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.
    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'

    Citation Envoyé par KsassPeuk Voir le message
    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.
    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.

    Citation Envoyé par KsassPeuk Voir le message
    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.
    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.

  9. #29
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 544
    Points
    544
    Par défaut
    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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
    Thanks.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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
    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.


    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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.
    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).

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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 ?
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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, ...). 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...).
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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...).
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    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é.
    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.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    A condition de disposer de plus de mémoire (3 à 6 fois plus pour bien tourner).
    Tu peux avoir une memory-footprint fitted à la centaine de Mo près dans un système qui run sur des Go de RAM.

  10. #30
    Membre régulier

    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    janvier 2010
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : janvier 2010
    Messages : 120
    Points : 120
    Points
    120
    Billets dans le blog
    1
    Par défaut Compilateur Rust
    Citation Envoyé par KsassPeuk Voir le message
    Et vous faites confiance au compilateur Rust ? Moi pas.
    Le compilateur Rust est fondé sur LLVM. On peut donc au moins lui faire à moitié confiance...
    jdd deschamps
    RPL - VB6 - C# - Wordpress - Python3 - Xamarin

  11. #31
    Membre confirmé Avatar de KsassPeuk
    Homme Profil pro
    Post-Doctorant
    Inscrit en
    juillet 2013
    Messages
    127
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Post-Doctorant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 127
    Points : 544
    Points
    544
    Par défaut
    Citation Envoyé par jdddeschamps Voir le message
    Le compilateur Rust est fondé sur LLVM. On peut donc au moins lui faire à moitié confiance...
    Je suis chiant, tant qu'il y a pas preuve formelle je fais pas confiance (pour ça que je fais pas confiance à GCC ou Clang non plus d'ailleurs ). Mais pour être un peu plus sérieux, je pense que dans les environnements critiques, on devrait se tourner d'avantage vers ces solutions.

  12. #32
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    1 060
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 1 060
    Points : 1 470
    Points
    1 470
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par koyosama Voir le message
    Je pense c'est juste penible de reinventer la roue. Refaire tout en Rust. Sans compter que les developpeurs avec les capacites pour developper ce genre d'appalication est rare de nos jours.
    Gerer un projet Open Source demande beaucoup de volonte.
    Je ne crois pas que ce soit vraiment nécessaire. Convertir tous ces programmes en C en C++ réduirait passablement les risques. Ce n'empêcherait pas toutes les fuites de mémoire car il y a toujours les risques des références circulaires. Mais ce risque existe pratiquement dans tous les langages.
    intel i7
    Mint 20
    Plasma et Cinnamon

  13. #33
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    1 060
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 1 060
    Points : 1 470
    Points
    1 470
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par jdddeschamps Voir le message
    Le compilateur Rust est fondé sur LLVM. On peut donc au moins lui faire à moitié confiance...
    Le problème avec une machine virtuelle est que tu as également une perte de performance.
    intel i7
    Mint 20
    Plasma et Cinnamon

  14. #34
    Membre expérimenté
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2004
    Messages
    1 060
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 1 060
    Points : 1 470
    Points
    1 470
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par Aurelien.Regat-Barrel Voir le message

    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.
    C'est beaucoup moins vrai quand les programmeurs adhère au modèle SOLID.
    intel i7
    Mint 20
    Plasma et Cinnamon

Discussions similaires

  1. problème installation à cause d'excel (référence)
    Par greg26 dans le forum Macros et VBA Excel
    Réponses: 4
    Dernier message: 17/09/2007, 10h14
  2. problème sérieux avec le DOM.
    Par g0up1l dans le forum Hibernate
    Réponses: 4
    Dernier message: 19/06/2007, 02h55
  3. Problème sérieux open_basedir sur un serveur virtuel
    Par microcongo dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 1
    Dernier message: 14/01/2007, 19h49
  4. [FLASH MX2004] Problème loading à cause du son
    Par zzman dans le forum Flash
    Réponses: 2
    Dernier message: 30/03/2006, 22h14
  5. Problème sérieux au démarrage
    Par onyouma dans le forum Windows XP
    Réponses: 1
    Dernier message: 27/02/2006, 12h48

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo