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 !

Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles
Mais peu de développeurs s'en soucieraient

Le , par Christian Olivier

338PARTAGES

14  1 
Un bogue affecte les iPhone, un autre touche Windows et un troisième affecte les serveurs tournant sous Linux. À première vue, ces bogues n’ont rien en commun puisqu’ils concernent des plateformes différentes : Android, iOS, macOS, Windows, Linux. La réalité serait cependant toute autre à en croire Alex Gaynor, ingénieur en sécurité logicielle chez Mozilla précédemment en poste chez USDS (United States Digital Service).

Lors de la troisième édition du « ;Weakest Link ;», le rendez-vous annuel organisé par Motherboard Vice sur le thème de l’avenir du piratage informatique et de la cybersécurité, Alex Gaynor a évoqué un problème sérieux qui, selon lui, menacerait Internet, mais qui semble paradoxalement laisser les développeurs complètement indifférents.

Gaynor a expliqué que les trois bogues évoqués précédemment existent parce que les logiciels qu’ils affectent sur les différentes plateformes ont été codés avec des langages de programmation qui ont la fâcheuse tendance de favoriser la survenue d’erreurs de type « ;memory unsafety ;», en autorisant l’accès aux régions invalides de la mémoire. Cette catégorie d’erreurs peut causer des bogues et des vulnérabilités de sécurité lors des procédures d’accès en mémoire.

En autorisant la survenue d’erreurs de type « ;memory unsafety ;», des langages de programmation tels que C et C++ auraient ainsi contribué à la dissémination d’un flux presque sans fin de failles de sécurité critiques pendant de nombreuses années. Comme exemple de ces vulnérabilités, on peut citer : les confusions de type, le dépassement de tampon, le dépassement de capacité d’entier et la vulnérabilité « ;use after free ;».

Les confusions de type peuvent survenir lorsqu’une portion de code ne vérifie pas le type d’objet qui lui est passé et l’utilise à l’aveuglette. Ce genre de situation peut s’avérer dangereuse dans la mesure où un type est exprimé comme une disposition dans l’implémentation de bas niveau d’un logiciel. De plus, avec les confusions de type, les mauvais pointeurs sur les fonctions ou les mauvaises données sont assignés à la mauvaise portion du code, ce qui peut dans certains cas conduire à une exécution du code.

Le dépassement de tampon (ou buffer overflow en anglais) est une faille de sécurité critique qui se produit lorsque l’utilisateur entre une chaine de caractères qui va se retrouver dans un tableau de caractères de taille insuffisante. Cela entraine l’écriture de données en dehors de la zone mémoire allouée pour le tableau. L’exploit HeartBleed, par exemple, qui a eu un impact sur 17 % des serveurs Web sécurisés sur Internet, était une vulnérabilité de dépassement de tampon permettant de lire 60 Ko après la fin d’une liste, y compris les mots de passe et autres données des utilisateurs.

Le dépassement de capacité d’entier, une faille difficile à détecter qui utilise le fait que les nombres ne peuvent dépasser une certaine valeur qui dépend du nombre de bits utilisés pour leur représentation et de leur méthode de codage.

La vulnérabilité « ;use after free ;» se présente, en général, dans le cas où on utilise un pointeur ou des données en mémoire, alors que le pointeur (ou le bloc mémoire) a déjà été libéré.


Ensemble, ces vulnérabilités représenteraient les exploits les plus fréquemment rencontrés dans des logiciels populaires tels que Firefox, Chrome, Windows, Android ou encore iOS. Gaynor en dénombre déjà au moins 400 et affirme : « ;Je suis les avis de sécurité pour ces projets depuis plus d’un an et, dans presque toutes les versions de ces produits, plus de la moitié des vulnérabilités sont de type memory unsafety. Plus troublant encore, les vulnérabilités sévères et critiques […] sont presque toujours de type memory unsafety ;».

Malgré les risques importants liés à la sécurité qu’ils font planer en permanence sur les logiciels qu’ils soutiennent, les langages de programmation « ;memory unsafety friendly ;» comme le C ou le C++ ont toujours la côte auprès des développeurs, alors que des alternatives éprouvées telles que Rust, Swift, pouvant être considérées comme des langages « ;memory safe ;» semblent à la traine.

Cette situation serait peut-être due au fait que, dans le cadre d’un nouveau projet, les développeurs ont tendance à opter pour un langage de programmation en fonction des langages que leur équipe connait, des performances et de l’écosystème de bibliothèques qui peuvent découler de ce choix. Le volet sécurité qu’implique ce choix n’est presque jamais considéré, ou du moins pas suffisamment, lors de la prise de décision estime Gaynor.

De plus, la plupart des projets logiciels, même les plus importants pour la sécurité d’Internet, ne sont pas nouveaux. Ils ont été lancés il y a une décennie ou plus. Linux, OpenSSL et le serveur Web Apache par exemple ont tous plus de vingt ans. Pour des projets d’envergure comme ceux-ci, réécrire tout le code dans un nouveau langage n’est pas une option. Ils ont besoin d’être transférés progressivement, ce qui implique que les projets devront être écrits et maintenus dans deux langages différents au lieu d’un seul. Cela suppose également qu’il faudra former une grosse équipe, ce qui prend beaucoup de temps et nécessite plus de moyens.

Le plus gros problème serait enfin lié au fait que beaucoup de développeurs ne croient pas du tout qu’il y a un problème. Ils ne croient pas que les langages comme C ou C++ facilitent ces vulnérabilités, mais que ce sont simplement d’autres ingénieurs qui écrivent du code bogué. Ils ne pensent pas qu’il y aurait un quelconque problème avec ces langages prétendument « ;memory unsafety friendly ;», car aucun code n’est parfait, mais simplement des personnes qui ne savent pas correctement les utiliser.

Source : Motherboard Vice

Et vous ?

Qu’en pensez-vous ?

Quel est ou quels sont vos langages de prédilection ?

Partagez-vous la théorie des langages « memory unsafety friendly » comme C ou C++ mise en avant dans cet article ? Expliquez votre point de vue.

Êtes-vous d’accord avec Gaynor lorsqu’il déclare que le volet sécurité est trop souvent négligé au moment du choix d’un langage ?

Voir aussi

Les pièges du C
Google publie des détails sur une faille non corrigée d'IE et Microsoft Edge qui a été signalée en fin novembre
C2 : un langage qui se présente comme une évolution de C plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements
Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ? Donnez votre avis

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

Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 16/11/2018 à 13:41
Non mais c'est un mystère pour personne en fait. Tous les acteurs du domaine le savent depuis genre 30 ou 40 ans.

Cependant, il faut déjà bien comprendre qu'on n'utilise pas ces langages dans les domaines en question parce que c'est les meilleurs, mais parce que ça a été les seuls capables d'amener au niveau de performances requis pendant des dizaines d'années (et on choisit très souvent de privilégier les performances à la fiabilité quand on veut vendre à un très grand nombre). Donc à la question "pourquoi Swift ou Rust mettent 'du temps' à décoller ?". Ils mettent pas du temps, ils viennent d'apparaître, on va pas transformer des milliards de lignes de code du C à C++ en deux coups de cuillère à pot, et c'est pas le tout que le langage existe, il faut former les gens aussi, ça va pas se faire en deux jours.

Ensuite, il vient la question d'assurer la fiabilité. Il est clairement possible d'assurer des niveaux de fiabilité très élevés sur des langages comme C et C++. C'est fait depuis des années dans le ferroviaire, l'aviation, l'armement, seulement il faut y mettre les moyens. Et rien ne dit qu'on atteindrait le même niveau facilement avec d'autres langages comme Rust. Je crois personnellement que c'est possible, effectivement, mais l'outillage d'un langage comme Rust est encore, dû à sa jeunesse, encore très loin des outils qui sont aujourd'hui disponibles pour C ou C++. Et vous faites confiance au compilateur Rust ? Moi pas. Mais pour C, il existe des choses du niveau de CompCert (et s'il y a des travaux préliminaires pour Rust, on en est encore très loin). Alors on prend quoi ? Un langage pour lequel j'ai pas d'outil avancé de vérification et un compilateur qui n'est pas sûr ? Ou un langage pour lequel j'ai des outils ultra avancé de vérification et un compilateur certifié par preuve formelle ?

Finalement, il faut pas oublier qu'il reste encore une option qui n'exclut pas des langages comme C. La génération de code correct par construction. Comme on peut le faire à partir de Lustre ou de langages comme Low-Star (basé sur F-Star). Je veux faire une lib de sécu, je fais quoi ? Je code en Rust sans aucune garantie que mon code est conforme à la spécification ? Où je l'écris en F-Star, je le prouve, je génère le C de manière certifiée et je le compile avec CompCert ? (Coucou HACL* !).
8  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 20/11/2018 à 2:19
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.
8  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 16/11/2018 à 14:16
Citation Envoyé par e101mk2 Voir le message
Pour ce qui est de Rust et Swift, je ne les connait que de noms. Mais si ils ont trouvée des solutions, c'est soit, la syntaxe du langage qui empêche ces problèmes, soit des instructions processeur supplémentaire qui alourdissement l’exécution.
Ce n'est pas syntaxique, c'est sémantique. Rust repose sur des "linear-types" (pour ceux qui veulent jeter un oeil à la partie théorique), pour garantir l'absence de runtime errors liées à la mémoire statiquement et permettre la libération automatique de mémoire sans GC, et de manière déterministe (et par comptage de référence si le développeur ne sait pas comment faire mieux). Il s'ajoute aussi à cela du contrôle automatique de bornes qui (en fait) dans la très vaste majorité des cas (pour ne pas dire tout le temps) peut être automatiquement virée par le compilateur. En gros, si un contrôle est laissé par le compilateur, ça veut très probablement dire que le développeur est de toute façon en train de faire une connerie.

Et c'est pour ça que ce serait intéressant d'avoir des analyseurs sémantiques encore plus puissants (du niveau de ce qu'on sait faire en C) pour Rust (interprétation abstraite par exemple), ça pourrait permettre de transmettre des hypothèses supplémentaires au compilateur pour virer encore plus de choses.
5  0 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 16/11/2018 à 19:08
Citation Envoyé par hotcryx Voir le message
Pourquoi ne pas adapter C/C++ tout simplement!
Ce serait déjà bien d'utiliser les fonctionnalités "modernes" du C++ : pointeurs intelligents, itérateurs, move semantic...
4  0 
Avatar de onilink_
Membre expérimenté https://www.developpez.com
Le 16/11/2018 à 14:26
Citation Envoyé par KsassPeuk Voir le message
Finalement, il faut pas oublier qu'il reste encore une option qui n'exclut pas des langages comme C. La génération de code correct par construction. Comme on peut le faire à partir de Lustre ou de langages comme Low-Star (basé sur F-Star). Je veux faire une lib de sécu, je fais quoi ? Je code en Rust sans aucune garantie que mon code est conforme à la spécification ? Où je l'écris en F-Star, je le prouve, je génère le C de manière certifiée et je le compile avec CompCert ? (Coucou HACL* !).
Intéressant, je ne connaissais pas F-Star. Reste a voir si ce n'est pas trop compliqué à utiliser.

Citation Envoyé par e101mk2 Voir le message
Si le C/C++ à de bonne performance, c'est parce que justement il ne vérifie pas si on va faire un buffer overflow, « ;use after free ;», ou la vérification de type. C'est au développeur de s'assurer qu'il y'en as pas, en rajoutant des instructions de vérification.
[...]
Pour ce qui est de Rust et Swift, je ne les connait que de noms. Mais si ils ont trouvée des solutions, c'est soit, la syntaxe du langage qui empêche ces problèmes, soit des instructions processeur supplémentaire qui alourdissement l’exécution.
En fait Rust est juste beaucoup mieux pensé que le C++ ou d'autres langages, pour la sécurité. Pour le comprendre il faut au moins lire un peu de documentation.
Le langage est beaucoup plus strict sur plein de niveaux, et il n'a effectivement pas peur de faire quelques concessions sur les performances (comme le bound checking), mais tout cela de manière intelligente (ainsi, si on code correctement il n'y aura que très peu de perte de performances, car le compilateur pourra supprimer pas mal de "checks".

Par contre, je le trouve difficile à apprendre. Certains disent que le C++ est difficile... il n'ont pas vu Rust
C'est un peu comme quand on tente d'apprendre Vulkan et que les premières lignes indiquent "contrairement a une API haut niveau comme OpenGL [...]"
3  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 18/11/2018 à 14:21
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.
3  0 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 16/11/2018 à 15:17
Citation Envoyé par Pyramidev Voir le message
Rust est plus éloigné de Java que ne l'est C++, surtout si on privilégie la programmation orientée objet quand on programme en C++.
Oui. Rust est plus un langage fonctionnel qu'objet donc forcément.

Concernant l'article, s'il a raison sur le fond, il est quand même un peu biaisé. Déjà dans les années 90, on ne risquait pas de coder en Rust ou en Swift... Ensuite C++ a beaucoup évolué donc il ne faudrait pas non plus comparer le Rust de 2018 avec le C++ de 98. Enfin Rust est poussé par Mozilla, donc l'avis d'un ingé de Mozilla n'est pas forcément des plus objectifs.
2  1 
Avatar de macos
Futur Membre du Club https://www.developpez.com
Le 16/11/2018 à 17:34
concernant la sécurité, si le C et C++ sont utilisées, il n'y as pas le choix, il faut monter en puissance, (projet de type aéronautique, ferroviaire, nucléaire, ..)
ensuite il faut un os certifie EAL avec le critère commun. il n'y as point de salue en dehors de méthode, de maitrise du compilateur et la validation applicative.
sinon il faut des langages typé forte. il en existe, mais certain sont désuet (pas obsolète mais trop peu l'utilisent, ADA 2012
il n'y as pas de recette miracle, et la montée en cybersécurité vont sans aucun doute amener à renforcer les outils, la vérifications , les tests, mais aussi les règles de codages.
1  0 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 17/11/2018 à 14:04
Citation Envoyé par hotcryx Voir le message
La solution de changer de langage n'est pas valable, celui ci entrainera d'autres failles.
Pas nécessairement justement. Quand tu as un système de types qui est designé à la base pour éviter les problèmes, il n'y aura pas d'autres failles. Ça ne veut pas dire qu'il est impossible qu'il y en ait. Mais si tu conçois ton langage avec cette idée en tête dès le début, tu limites beaucoup plus fortement les possibilités (par exemple pour Rust, il y a déjà de très bonnes raisons de penser que ce qu'ils avancent en terme de sécurité soit vrai : https://plv.mpi-sws.org/rustbelt/popl18/paper.pdf). D'autre part, en repartant d'un design beaucoup plus simple, tu augmentes tes chances de voir arriver un jour une version formellement prouvée du bousin. Ce qui est juste hors de portée pour C++ par exemple.

Citation Envoyé par hotcryx Voir le message
Pourquoi ne pas adapter C/C++ tout simplement!
Certe c'est fastudieux mais ces langages sont supportés...
C'est pas fastidieux. Pour C, c'est simplement impossible parce qu'il n'y a rien dans le système de base qui permette d'obtenir quelque chose de semblable, donc en fait ça reviendrait à en faire un autre langage. Pour C++, c'est impossible dans un délai raisonnable et en plus, contrairement à tout autre langage conçu avec une optique de sécurité à la base, ça ne permettrait d'obtenir aucune garantie puisque tout le reste du langage doit rester supportée.

Et ça n'enlèverait absolument en rien le fait que tout le reste de ces deux langages est bourré d'incohérence et de contradiction. Pour C, on a un compilateur certifié (qui a dû renforcer certaines choses de la norme sinon c'était impossible), on sait vérifier que du code est exempt de runtime-errors, sauf que c'est très coûteux. Pour C++, le compilateur certifié, ça impliquerait d'avoir du monde pour spécifier mathématiquement une norme de 1400 pages (on est bien parti), dont certaines parties sont déjà très mal définies en anglais, et qui continue à croître à une vitesse folle.

Bref, il y a des limites à l'adaptation, principalement fixées par la manière dont le langage a été pensé à la base.

Pour ce qui est du support, il y a déjà des PoC de compilateurs Rust -> C par exemple. Ce qui fait qu'on peut virtuellement compiler du Rust vers n'importe quoi.

Citation Envoyé par JPLAROCHE Voir le message
Bonjour, je code en c++2018 gcc8.2 avec les options mise en place la compilation détecte beaucoup d'erreur qui passaient il y a plusieurs années.
C'est vrai, mais malheureusement, c'est complètement insuffisant pour garantir des propriétés de sécurité, même simplistes comme des accès mémoire. Et une base de test ne sera jamais suffisante pour garantir la sécurité sur des parties vraiment critiques des systèmes qu'on utilise en permanence (systèmes d'exploitation, protocoles de communication, ...). Et ça c'est sans parler des propriétés fonctionnelles pour lesquels Rust, ou Swift, ou Go, ne sont absolument pas équipés. On a des outils pour C par contre (ou autres langages du genre), et il serait intéressant de les adapter à des langages comme Rust, parce qu'on pourrait prouver des propriétés compliquées tellement plus facilement qu'en C ! (Et il y a aussi des options comme ce que j'ai mis plus haut à propos de génération depuis des langages très haut niveau).
1  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 17/11/2018 à 18:38
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".
2  1