Heartbleed, OpenSSL et la question de la sécurité expliqués simplement

Heartbleed, OpenSSL et la question de la sécurité expliqués simplement

Quatre questions, quatre réponses

Avatar de l'auteur
David Legrand

Publié dans

Internet

09/04/2014 13 minutes
199

Heartbleed, OpenSSL et la question de la sécurité expliqués simplement

Lundi soir, une faille importante était annoncée au sein d'OpenSSL. Comme nous l'avions évoqué hier, celle-ci pourrait avoir des conséquences assez graves, mais elle n'a pour autant pas soulevé de grandes réactions en France, bien que la presse semble commencer à s'en emparer. Devant le besoin de pédagogie sur une question aussi complexe, nous avons décidé de tenter de la rendre compréhensible au plus grand nombre en répondant à quelques questions claires.

Depuis lundi soir, le hashtag #Heartbleed semble affoler de plus en plus de monde. Au départ ils n'étaient que quelques administrateurs système, mais au fur et à mesure des billets et des articles évoquant le sujet, l'ampleur va en grandissant. En France, cela n'a pas tout de suite été le cas, et l'on notait encore ce matin de nombreux sites d'information qui n'en avaient toujours pas parlé, ce qui devrait aller mieux suite à la publication d'une dépêche AFP. D'autres ne s'étaient toujours pas prémunis contre cette faille béante, qui pourrait pourtant avoir de graves conséquences. Une situation assez bien résumée en un tweet de Stéphane Bortzmeyer publié hier : 

 

 

Nous avons donc décidé de résumer tout ce qu'il faut savoir afin de comprendre le sujet, pouvoir en parler autour de vous et sensibiliser votre entourage, en attendant que les choses se tassent et que la majorité des sociétés concernées ne réagisse publiquement, sans doute dans la journée ou les jours à venir. Il sera alors temps de faire le point sur les conséquences exactes.

Heartbleed, c'est quoi ?

Comme nous l'expliquions hier, Heartbleed est une faille dévoilée hier au sein d'une extension d'OpenSSL. Cet outil open source est assez largement utilisé sur internet afin de sécuriser les communications entre votre ordinateur et un serveur. C'est le fameux cadenas dont on vous dit qu'il est nécessaire pour s'assurer de votre sécurité, notamment dans le cadre d'un paiement en ligne. Ce n'est pas le seul service de ce genre qui existe, mais il est très largement exploité, y compris par des sites de vente en ligne, des banques, etc.

 

Il est capable grâce à l'extension Heartbeat de créer une communication dite de longue durée (détaillée ici). Pour cela, votre machine et le serveur s'envoient de petits messages réguliers pour s'assurer qu'ils sont toujours en contact. C'est cela les fameux battements de cœur dont il est question et qui ont donné naissance au nom et au logo de la faille :

 

Heartbleed 

Heartbleed, un nom et un logo bien trouvés 

 

Malheureusement, depuis OpenSSL 1.0.1, introduit en 2012, un bug permet à n'importe qui d'aller lire aléatoirement de petites quantités (jusqu'à 64 ko) de données non chiffrées, stockées dans la mémoire serveur auquel vous êtes connecté, et cela, via une simple requête. Celui-ci n'a été corrigé que hier avec la version 1.0.1g, et tous les sites touchés doivent se mettre à jour et redémarrer les services qui utilisaient OpenSSL afin de combler cette faille. Ceux qui utilisaient une version antérieure ne sont pas concernés, une prochaine bêta de la branche 1.0.2 fera de même.

 

Un doute existe quant à la possibilité que les clefs privées qui permettraient de déchiffrer les échanges aient pu être récupérées. Il est donc conseillé d'en générer de nouvelles pour ceux qui gèrent des serveurs exploitant OpenSSL. Si cela était confirmé, cela voudrait dire que n'importe quel échange chiffré récupéré par un tiers ces dernières années, pourra désormais être lu en clair. C'est un point qui a spécifiquement fait réagir l'Electronic Frontier Foundation (EFF) qui appelle à une utilisation plus massive d'une couche de sécurité supplémentaire : Perfect Forward Secrecy.

Si un site est indiqué comme vulnérable, dois-je m'en méfier ?

Comme l'on pouvait s'y attendre, de très nombreux sites ont été touchés, parfois même certains géants du web. Un outil qui permet de tester un domaine en particulier a été mis en ligne, et selon nos constatations, on peut trouver des données sensibles dans de nombreux cas, même sur des sites français. Hier, une liste complète avait été mise en ligne, dans la soirée, on trouvait encore de nombreux exemples de sites vulnérables chez nous que nous avons vérifié : CuisineAZ, Castorama, Elle, Europe 1, Millenium, Paris.fr, Premiere, Slate, et Sports.fr.

 

Mais ce qu'il faut bien comprendre, c'est que ce n'est pas parce qu'un site est indiqué comme vulnérable que des données sensibles peuvent être récupérées. Nous avons par exemple contacté Slate hier pour leur indiquer suite à leur article qu'ils étaient eux-mêmes touchés, mais ils nous ont confirmé qu'ils n'utilisaient pas OpenSSL dans la pratique. Et effectivement, assez peu de données pouvaient être récupérées, aucune n'étant sensible.

 

Dans la majorité des cas, on retrouve en effet uniquement le code source des pages visitées par les utilisateurs, ce qui n'a rien de vraiment gênant puisque ces pages sont en générales publiques. 

 

 

Cela devient par contre problématique lorsqu'un site vous permet d'échanger avec lui des informations importantes dans un environnement sécurisé. Il y a notamment deux cas qui posent soucis : celui des identifiants de connexion et des cookies, mais aussi celui des données données relatives à un service bancaire. Et des cas assez graves ont été relevés. 

 

Désormais, une majorité de sites ont été patchés, surtout ceux qui contenaient des informations sensibles. Le mieux est néanmoins d'attendre encore quelques jours avant de vous reconnecter, et de modifier vos mots de passe d'ici là. Faites aussi très attention aux mails que vous allez recevoir dans les mois à venir afin d'éviter les tentatives de Phishing. D'ailleurs, ne donnez JAMAIS aucun élément de sécurité à un tiers, même sur un site ressemblant à celui de votre banque ou d'un service quelconque sans vous être assuré de sa véracité, notamment de celle de l'adresse de la page sur laquelle vous vous trouvez.

 

La gendarmerie a mis en ligne une page explicative avec des contacts à utiliser en cas de problème. Vous pourrez aussi effectuer un signalement via la plateforme Pharos ainsi que sur phishing initiative

Mes identifiants de connexion sont-ils en danger ?

Il y a de fortes chances que oui, mais ce n'est pas systématique. Il faut en effet savoir que dans une phase de connexion, la majorité des sites utilise un système assez simple, et les procédures réellement sécurisées sont rares. Le cas le plus courant est de voir un site vous demander votre pseudonyme ou votre email, ainsi que votre mot de passe. Ceux-ci sont envoyés au serveur qui va ensuite les vérifier. Et dans la majorité des cas, tout ceci se passe sans aucun chiffrement. En effet, vos éléments de sécurité transitent en clair sur le réseau, c'est notamment pour cela qu'il est souvent recommandé de ne pas se connecter à certains sites si vous êtes sur un réseau Wi-Fi public. C'est aussi notamment pour cela que nous avons récemment décidé de revoir notre procédure de connexion à l'occasion de l'introduction de notre système unifié.

 

Les plus attentifs aux questions de sécurité pourront s'étonner : Pourquoi le « hash » du mot de passe, une variable qui permet de vérifier sa véracité mais qui ne permet (normalement) pas de le retrouver, n'est-il pas calculé puis envoyé au serveur ? Tout d'abord, cela ne ferait que déporter le problème, puisque le hash suffirait alors pour faire croire à une identification réelle. En fait, il y a une raison principale, bien que d'autres éléments plus techniques y participent aussi : pour des raisons de sécurité mises en lumière par plusieurs piratages récents, le calcul n'est pas effectué sur votre machine puisqu'il nécessite une composante aléatoire qui ne doit être connue que du serveur : le « salt ». Cela renforce la sécurité du hash et réduit les chances de pouvoir l'utiliser afin de retrouver le mot de passe de l'utilisateur. Le mot de passe est donc envoyé au serveur, le hash est calculé avec la composante aléatoire, et le tout est vérifié afin de savoir si l'utilisateur peut ou non se connecter.

 

Idéalement, donc, tous les sites devraient utiliser une connexion sécurisée pour l'échange de ces données, mais ce n'est pas le cas. Ici, ils ont néanmoins été sauvés puisque n'utilisant pas de chiffrement, ils n'ont pas risqué de se retrouver face à une faille du système de chiffrement. D'autres ont par contre été touchés et cela peut avoir des incidences graves.

 

Le dernier point à aborder pour la question de la connexion est celui des cookies de session. En effet, une fois connecté, le site place un petit fichier dans votre machine afin de vous éviter de vous reconnecter à chaque visite : un cookie. Ceux-ci peuvent aussi dans certains cas être récupérés et recrées par un attaquant qui pourra ainsi se connecter à votre place, même sans connaître vos identifiants. Là aussi il s'agit d'un problème grave, notamment lorsque des éléments importants sont indiqué dans les comptes des utilisateurs.

 

 

Yahoo! a par exemple été assez vite repéré puisque des relevés ont montré que des mots de passe pouvaient être récupérés via cette faille. La société n'a communiqué que tardivement et discrètement sur le sujet et a mis à jour l'ensemble de ses serveurs dans la fin de journée d'hier. LastPass a par contre communiqué assez ouvertement, comme de nombreux autres, et a indiqué que sa procédure était un peu plus sécurisée que la moyenne, mais que la potentielle fuite des clefs privées pouvait être un problème. La société a de son côté mis en ligne un site permettant de savoir si un site pouvait être touché et de quand datait le certificat utilisé pour le chiffrement, ce qui permet de savoir si il a récemment été renouvellé ou non.

 

Un autre cas relevé est celui de Darty. Si le domaine principal du revendeur est touché, ce n'est pas le seul. Et celui qui gère la sécurité de la connexion des membres l'est aussi. C'est encore le cas à l'heure où nous écrivons ces lignes et nous avons pu récupérer des identifiants / mot de passe en quelques minutes. Si vous êtes client de l'enseigne et que vous vous êtes connecté récemment, changez donc au plus vite vos mots de passe sur tous vos autres services en attendant qu'elle ne corrige cette faille. Pour le moment, il nous a simplement été indiqué que ses équipes étaient alertées et travaillaient à la résolution du souci, qui n'est toujours pas corrigé :

 

Dois-je m'inquiéter pour ma carte bleue et l'accès à mes comptes ?

L'autre cas sensible est celui des services bancaires. Là, deux points sont à surveiller : le premier concerne la connexion à vos comptes en ligne. Certains services ont été touchés, mais tout semble désormais corrigé. Si vous vous êtes connectés à votre compte dans les deux jours qui viennent de s'écouler, il est donc préférable de chercher à changer de mot de passe par sécurité. Nous avons contacté de nombreux organismes afin qu'ils nous confirment s'ils ont été concernés ou pas et quelles sont les procédures mises en place pour leurs clients. Des associations telles que l'AFUB ou l'UFC Que Choisir devraient d'ailleurs assez rapidement s'emparer du sujet.

 

L'autre problème concerne les systèmes de paiement en ligne utilisés par les sites de vente. Car oui, certains ont été touchés. C'est notamment le cas de celui du groupe CIC / Crédit Mutuel. D'après nos relevés, certains domaines du groupes étaient vulnérables, mais cela a été ensuite résorbé. Dans le cas du Crédit Mutuel par exemple, tout est rentré dans l'ordre ce matin. C'est ce qui nous a poussés à couper l'accès à nos abonnements puis à le réouvrir dans la matinée. Le site Capitaine Train a d'ailleurs fait de même, ou a plutôt opté pour le service Paybox en attendant que le prestataire de la banque soit mis à jour.

 

Crédit Mutuel Heartbleed

Le système de paiement du Crédit Mutuel était vulnérable jusqu'à ce matin, vers 8h

 

Pour autant, est-ce que votre numéro de carte bleue est en danger ? Nous n'avons pas trouvé de trace confirmant que de telles informations avaient pu être récupérées en clair. Cela ne veut pas dire que cela n'a pas été le cas, mais nous ne pouvons pas l'affirmer. Là aussi nous avons interrogé les banques pour en savoir plus, et l'on devrait apprendre de nombreux détails avec le recul.

 

D'après nos constatations, un attaquant pouvait néanmoins récupérer de nombreuses informations : l'e-mail d'un acheteur, le site où il a effectué son achat, le montant de la transaction, etc. Bref, dans le meilleur des cas, tout ce qu'il faut pour lancer une bonne campagne de phishing. Là aussi donc, soyez prudent sur les emails que vous allez recevoir dans les mois à venir, et surveiller vos comptes : en cas de problème, prévenez immédiatement votre banque, qui se doit d'agir.

 

Bien entendu, de nombreux nouveaux éléments vont arriver sur le sujet dans les jours à venir. Nous n'hésiterons pas à faire des points réguliers et à mettre à jour cette actualité si nécessaire. En attendant, si vous avez la moindre question, n'hésitez pas à la poser au sein de nos commentaires, cela pourra éventuellement nous aider à compléter cet article.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Heartbleed, c'est quoi ?

Si un site est indiqué comme vulnérable, dois-je m'en méfier ?

Mes identifiants de connexion sont-ils en danger ?

Dois-je m'inquiéter pour ma carte bleue et l'accès à mes comptes ?

Fermer

Commentaires (199)


Steam semblerait touché.


Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />


Merci pour cette synthèse PCi, heu NEXTi <img data-src=" />


Donc, si je comprends bien, si on ne s’est pas connecté à un site compromis, il n’y a pas de problème ?



Genre, quelqu’un qui ne se serait pas connecté à Yahoo dans les 2 dernières semaines ne risque pas d’avoir son mot de passe dans la nature.


A noter que dans les cas de la carte bleue stricto sensu, la loi impose à la banque de prendre en charge toute utilisation frauduleuse des moyens de paiement qu’elle met à votre disposition.



Donc même si vous vous retrouvez victime d’une fraude, la banque doit vous rembourser.


Donc si j’ai bien compris, si on s’est connecté sur un site vulnérable entre la découverte de la faille et aujourd’hui, il est indispensable de changer le mot de passe. Mais si on ne s’est pas connecté, les risques de piratage sont moindres mais ça n’évite pas le risque zéro.


Question : si on est toujours co sur ledit site ( et que dont on a jamais fait déco-reco ) il y a risque ou pas ?




un bug permet à n’importe qui d’aller lire de petites quantités (jusqu’à 64 ko) de données non chiffrées



Heu…64ko de données non chifrées, c’est énorme.<img data-src=" />








Ricard a écrit :



Heu…64ko de données non chifrées, c’est énorme.<img data-src=" />







Ce n’est pas la quantité d’info qui est importante, c’est la qualité ! Avec une bonne prise, tu peux faire ce que tu veux avec <img data-src=" />



Quand je pense à tous les tests que doivent faire les administrateurs système pour être sure que la mise à jour soit bonne, il y en a qui ont pas du dormir cette nuit <img data-src=" />



La version bugguée date de 2012, et on coupe les sites depuis hier ? <img data-src=" />



On sait de qui est sortie l’info de cette faille ? Qui l’a dévoilé, et quand exactement ? Ca a été corrigé avant ou après la divulgation ?


http://filippo.io/Heartbleed/#btce.com



bon les markets sont aussi touché ^^ <img data-src=" />








Jarodd a écrit :



La version bugguée date de 2012, et on coupe les sites depuis hier ? <img data-src=" />



On sait de qui est sortie l’info de cette faille ? Qui l’a dévoilé, et quand exactement ? Ca a été corrigé avant ou après la divulgation ?





http://heartbleed.com/



<img data-src=" />






le première concerne la connexion à vos comptes en ligne. Certains services ont été touchés, mais tout semble désormais corrigé. Si vous vous êtes connectés à votre compte dans les deux jours qui viennent de s’écouler,





Je ne comprends vraiment pas ce point là.

Si la faille existe depuis 2012, pourquoi ne s’inquiéter que pour les deux derniers jours de connexion ?



A part la connaissance du problème qui a été mis en lumière, et as donc multiplié les risque de compromission.

Mais, c’est si on a fait de l’interner depuis 2012 qui est un facteur de risque.



Est ce que quelqu’un a une meilleure explication ?








hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />





+1000 ….









hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />





Qui a dit ça ?









hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />









charon.G a écrit :



+1000 ….





Faut pas venir se plaindre de se faire basher pour MS fanboyisme après des poncifs pareils…



C’était sur OpenSSL qu’il y avait des soupçons de backdoor à un moment.

Et que le code avait était relu pour plein de monde.

Et personne a vu la faille à ce moment là…il a du être bien relu le code <img data-src=" />








ActionFighter a écrit :



Faut pas venir se plaindre de se faire basher pour MS fanboyisme après des poncifs pareils…







J’ai cru un moment être ‘dredi, Ô sainte journée des trolls.

Puis, non, aujourd’hui, c’est ‘credi… je me sens tout déçu…









typhoon006 a écrit :



C’était sur OpenSSL qu’il y avait des soupçons de backdoor à un moment.

Et que le code avait était relu pour plein de monde.

Et personne a vu la faille à ce moment là…il a du être bien relu le code <img data-src=" />





Ouais d’ailleurs en relisant un code correctement on trouve tous les bugs. D’ailleurs, la détection de bug c’est complètement trivial.









ActionFighter a écrit :



Faut pas venir se plaindre de se faire basher pour MS fanboyisme après des poncifs pareils…





c’est beau de nier maintenant. Hadoken a entièrement raison. Sur pci j’ai eu affaire plusieurs fois à ce genre de personnes qui tenaient ce genre de discours. Enfin bref je m’arrête la ca commence directement dans la mauvaise foi.









ActionFighter a écrit :



Faut pas venir se plaindre de se faire basher pour MS fanboyisme après des poncifs pareils…







Pourquoi tu sites que M$ ? Tu fais le fanboy ? <img data-src=" />









Jarodd a écrit :



La version bugguée date de 2012, et on coupe les sites depuis hier ? <img data-src=" />



On sait de qui est sortie l’info de cette faille ? Qui l’a dévoilé, et quand exactement ? Ca a été corrigé avant ou après la divulgation ?







OpenSSL indique c’est une personne de Google Security qui a découvert cette faille et informé OpenSSL. Elle a ensuite été corrigée et un bulletin d’alerte est tombé <img data-src=" />









charon.G a écrit :



c’est beau de nier maintenant. Hadoken a entièrement raison. Sur pci j’ai eu affaire plusieurs fois à ce genre de personnes qui tenaient ce genre de discours. Enfin bref je m’arrête la ca commence directement dans la mauvaise foi.





Il n’y a pas que ça il y aussi les personnes qui viennent t’expliquer qu’on peut écrire sécurisé en C++ et qu’il suffit de relire le code pour limiter les failles. Il y’avait encore une news la dessus il y a quelques jours sur .NET…









typhoon006 a écrit :



Et personne a vu la faille à ce moment là…il a du être bien relu le code <img data-src=" />







Avec plus de 400000 lignes source, pas facile d’être sur à 100%









malock a écrit :



J’ai cru un moment être ‘dredi, Ô sainte journée des trolls.

Puis, non, aujourd’hui, c’est ‘credi… je me sens tout déçu…





Pour certains, c’est tous les jours Dredi <img data-src=" />







charon.G a écrit :



c’est beau de nier maintenant. Hadoken a entièrement raison. Sur pci j’ai eu affaire plusieurs fois à ce genre de personnes qui tenaient ce genre de discours. Enfin bref je m’arrête la ca commence directement dans la mauvaise foi.





Le “maiheuuu, c’est lui qu’à commencéheuuu”, ça marche en cours de récré, mais sur un le net, ça ne fait qu’alimenter des petites guéguerres qui n’ont pas lieu d’être.









Cara62 a écrit :



Pourquoi tu sites que M$ ? Tu fais le fanboy ? <img data-src=" />





Non, le hater de fanboy <img data-src=" />







charon.G a écrit :



Il n’y a pas que ça il y aussi les personnes qui viennent t’expliquer qu’on peut écrire sécurisé en C++ et qu’il suffit de relire le code pour limiter les failles. Il y’avait encore une news la dessus il y a quelques jours sur .NET…





Un code ne sera jamais sécurisé à 100% quelque soit la techno.



Prendre un exemple pour détourner des arguments, ça c’est de la pure mauvaise foi.









mistigrite a écrit :



Qui a dit ça ?





La FSF



Et ils se défaussent en disant que le bug a été corrigé grâce à l’ouverture du code, tout en passant en silence le fait qu’il a quand même fallu deux ans pour le découvrir : http://www.fsf.org/news/free-software-foundation-statement-on-heartbleed-vulnerability









ActionFighter a écrit :



Pour certains, c’est tous les jours Dredi <img data-src=" />





Le “maiheuuu, c’est lui qu’à commencéheuuu”, ça marche en cours de récré, mais sur un le net, ça ne fait qu’alimenter des petites guéguerres qui n’ont pas lieu d’être.





a force de troller la dessus il faut pas raler sur le retour de baton…

Un peu facile ta remarque. enfin bref je vous laisse dans votre deni mais j’ai bien rigolé…









mistigrite a écrit :



Qui a dit ça ?





C’est clair, j’ai failli réagir, et je puis je me suis dit… à quoi bon, ce n’est qu’un <img data-src=" />









ActionFighter a écrit :



Non, le hater de fanboy <img data-src=" />





Un code ne sera jamais sécurisé à 100% quelque soit la techno.



Prendre un exemple pour détourner des arguments, ça c’est de la pure mauvaise foi.





les buffer overflow c’est la très grande majorité des failles et ce n’est pas possible avec un langage managé…



Quelqu’un aurait un lien vers une analyse bien didactique du truc?



De ce que j’ai lu jusqu’ici la faille permet de récupérer un bloc de 64k de données dont l’emplacement en mémoire m’a l’air non prévisible.

De la à récupérer comme c’est écrit comptes et mot de passe sur n’importe quel serveur web affecté il me semble qu’il y ait un peu de marge (mais je peux me tromper)









charon.G a écrit :



Sur pci j’ai eu affaire plusieurs fois à ce genre de personnes qui tenaient ce genre de discours.







Et tu n’es pas assez “aware” pour te rendre compte que ce genre de personnes sont de bons vieux trolls ? Non, tu fonces tête baissée, coudes au corps !



Hit : des trolls, il y en a autant chez les “pro-proprio” que chez les barbus jurant que par la ligne de commande… dingue !










charon.G a écrit :



Il n’y a pas que ça il y aussi les personnes qui viennent t’expliquer qu’on peut écrire sécurisé en C++ et qu’il suffit de relire le code pour limiter les failles. Il y’avait encore une news la dessus il y a quelques jours sur .NET…





Je suis d’accord sur un point : penser qu’une relecture poussée suffira à trouver et corriger toutes les failles est idiot.

En revanche, je suis effectivement convaincu qu’on peut écrire du code sécurisé dans n’importe quel langage. Le problème c’est se donner les moyens de le faire. Cela passe par un travail de formalisation qui est loin d’être trivial mais reste de l’ordre du faisable.









charon.G a écrit :



les buffer overflow c’est la très grande majorité des failles et ce n’est pas possible avec un langage managé…





Ah c’est nouveau ça, “langage managé”…?! Tu veux dire “code managé”…? <img data-src=" />









hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />







L’open source (et surtout le Libre, faut pas tout confondre) permet par exemple de ne pas compiler l’option “HeartBeat” de la librairie OpenSSL pour ne pas être impacté par cette faille…



Et ce avant même qu’une solution soit imaginée ou diffusée !



Beaucoup de système dit “stables” utilisés en entreprises vont également s’appuyer sur des librairies plus ancienne et éprouvées, typiquement OpenSSL 0.9.8 qui n’est pas impacté est encore très utilisé (Red Hat 6 est livré avec une version 1.0.0 qui n’est pas affectée…)



La liberté permet toujours plus que la privation <img data-src=" />










charon.G a écrit :



les buffer overflow c’est la très grande majorité des failles et ce n’est pas possible avec un langage managé…





Et c’est bien connu que le code managé est l’unique propriété du monde proprio.







Ksass`Peuk a écrit :



Je suis d’accord sur un point : penser qu’une relecture poussée suffira à trouver et corriger toutes les failles est idiot.

En revanche, je suis effectivement convaincu qu’on peut écrire du code sécurisé dans n’importe quel langage. Le problème c’est se donner les moyens de le faire. Cela passe par un travail de formalisation qui est loin d’être trivial mais reste de l’ordre du faisable.





C’est ce que j’avais dis à l’époque.



Le gros avantage de l’open-source en soit n’est pas le fait qu’il n’y a pas de failles, c’est évident.



Par contre, et on en a encore un bel exemple ici, lorsqu’une faille est découverte, elle est généralement corrigé dans les heures qui suivent, et tout est mis à jour, au niveau des dépôts, très rapidement.



Ici, la faille a été corrigée avant d’être divulguée, et c’est ça, la grande force de l’open-source versus le proprio.



Je ne suis pas contre le proprio, j’en utilise tous les jours (je développe en .net), mais clairement, ici, il s’agit d’un net avantage.








ActionFighter a écrit :



Et c’est bien connu que le code managé est l’unique propriété du monde proprio.





C’est ce que j’avais dis à l’époque.





J’ai jamais dit ca



maxxyme a écrit :



Ah c’est nouveau ça, “langage managé”…?! Tu veux dire “code managé”…? <img data-src=" />





Ca se dit aussi langage safe si tu préfères. Tu joues sur les mots…









ActionFighter a écrit :



Et c’est bien connu que le code managé est l’unique propriété du monde proprio.





C’est ce que j’avais dis à l’époque.





Et j’ai jamais dit le contraire , quand je parle de langage safe, ça inclut aussi java.









ActionFighter a écrit :



Non, le hater de fanboy <img data-src=" />





Un code ne sera jamais sécurisé à 100% quelque soit la techno.



Prendre un exemple pour détourner des arguments, ça c’est de la pure mauvaise foi.





C’est ce que fait tout bon politicien <img data-src=" />









charon.G a écrit :



a force de troller la dessus il faut pas raler sur le retour de baton…

Un peu facile ta remarque. enfin bref je vous laisse dans votre deni mais j’ai bien rigolé…





Tu es franchement de mauvaise foi.



Oui, il y a des intégristes qui vont raconter des trucs faux, par exemple que le libre est tout-sécurisé. C’est faux, c’est du troll primaire, je suis d’accord.



Mais que tu te bases sur ces gens-là pour dénigrer tout le libre, comme ça a été fait dans le message ci-dessus, c’est franchement très mal venu. Le message de hadoken était un troll, tu l’as plussoyé, ça en dit long.



Ballmer disait que le libre était un cancer. Je vois que tu as exactement les mêmes travers, tu fais des amalgames pas possibles. Je te croyais plus nuancé, je vois que tu es foncièrement anti-libre en fait.









CoooolRaoul a écrit :



Quelqu’un aurait un lien vers une analyse bien didactique du truc?







il y a une bonne explication, ainsi que le code source ici
















ActionFighter a écrit :



Et c’est bien connu que le code managé est l’unique propriété du monde proprio.





Mouais, c’est surtout la bonne solution pour pouvoir laisser les stagiaires codés et penser qu’on ne risque rien et qu’on peut gagner encore plus d’argent.









charon.G a écrit :



J’ai jamais dit ca





Dans ce cas, je ne vois pas ce que vient faire l’anecdote sur le C++ dans le débat, à part essayer de me décrédibiliser dans mes remarques à ton égard sur la base de mes propos sur un autre débat.









Ksass`Peuk a écrit :



Je suis d’accord sur un point : penser qu’une relecture poussée suffira à trouver et corriger toutes les failles est idiot.

En revanche, je suis effectivement convaincu qu’on peut écrire du code sécurisé dans n’importe quel langage. Le problème c’est se donner les moyens de le faire. Cela passe par un travail de formalisation qui est loin d’être trivial mais reste de l’ordre du faisable.





C’est possible sur des projets de petites tailles comme les hyperviseurs mais sur un projet comme un os, difficilement réalisable.









TaigaIV a écrit :



Mouais, c’est surtout la bonne solution pour pouvoir laisser les stagiaires codés et penser qu’on ne risque rien et qu’on peut gagner encore plus d’argent.





Mauvaise foi.



Aucun stagiaire ne code sur Java ou .Net, ce sont des “consultants juniors avec deux ans d’expérience”.









240-185 a écrit :



La FSF





Je ne dois plus savoir lire l’anglais. C’est à quel endroit que c’est indiqué que les logiciels open source n’ont pas de faille ?









Konrad a écrit :



Tu es franchement de mauvaise foi.



Oui, il y a des intégristes qui vont raconter des trucs faux, par exemple que le libre est tout-sécurisé. C’est faux, c’est du troll primaire, je suis d’accord.



Mais que tu te bases sur ces gens-là pour dénigrer tout le libre, comme ça a été fait dans le message ci-dessus, c’est franchement très mal venu. Le message de hadoken était un troll, tu l’as plussoyé, ça en dit long.



Ballmer disait que le libre était un cancer. Je vois que tu as exactement les mêmes travers, tu fais des amalgames pas possibles. Je te croyais plus nuancé, je vois que tu es foncièrement anti-libre en fait.





Je parlais de ces trolls. Enfin bref je vous laisse vous pignoler entre vous.

Moi anti libre c’est très drôle, tu n’as pas lu mon premier commentaire sur la news .NET. J’évoque depuis longtemps que Microsoft passera au libre.



Concernant le paragraphe sur l’identification.



Pourquoi ne pas envoyer le pass hashé au serveur qui se chargera de le hasher à nouveau, mais en incluant cette fois le salt.



De cette manière, le mot de pass n’est pas transmis en clair et le simple fait d’envoyer le hash “de base” ne valide pas l’identification.





C’est une méthode que j’utilisais il y a quelques temps. (En utilisant du SHA-2)


C’est fou la mauvaise foi quand même.



Quand on parle de code proprio tout de suite tout le monde nous tombe dessus “bouh les backdoors de la NSA”, “code buggé”, “privation de liberté”, “M$”, “FOSS = ton code sera relu = pas de faille”…etc.



Par contre quand un problème arrive sur une lib ultra connue en licence libre, personne n’a envie de voir en face le fait que les process de l’open source ne sont pas la silver bullet qui rend l’humanité meilleure à tous points de vue…



Prenez aussi la peine de regarder les liens fournis par 240-185 en page 3, c’est assez symptomatique de l’aveuglement des gourous du librisme.








charon.G a écrit :



Je parlais de ces trolls. Enfin bref je vous laisse vous pignoler entre vous.

Moi anti libre c’est très drôle, tu n’as pas lu mon premier commentaire sur la news .NET. J’évoque depuis longtemps que Microsoft passera au libre.





Au libre, je ne pense pas.



A l’open-source, plutôt.









charon.G a écrit :



C’est possible sur des projets de petites tailles comme les hyperviseurs mais sur un projet comme un os, difficilement réalisable.





J’ai jamais dit que c’était facile <img data-src=" /> .

Après augmenter sa capacité à créer du code non-managé sûr permet de s’affranchir du management quand son surcoût n’est pas acceptable par rapport au coût de l’opération “réelle” (si on peut dire). Cela permet d’avoir plus de liberté pour trouver un juste milieu.









ActionFighter a écrit :



Mauvaise foi.



Aucun stagiaire ne code sur Java ou .Net, ce sont des “consultants juniors avec deux ans d’expérience”.





et qui deviendront “consultant senior” à la fin de leur sta… heu… à la fin de leur première expérience de 6 mois… heu… de 3 ans









Konrad a écrit :



Ballmer disait que le libre était un cancer. Je vois que tu as exactement les mêmes travers, tu fais des amalgames pas possibles. Je te croyais plus nuancé, je vois que tu es foncièrement anti-libre en fait.







Charon est clairement de mauvaise foi (je suis aussi un peu déçu mais bon… il a ptêt mal dormi, je sais pas <img data-src=" />) de là à dire qu’il est anti libre…



Du coup il va devoir arrêter de dev avec des technologies MS vu tous le dernier volet qui viens d’être ouvert dont une partie directement tourné vers le futur pour MS.









typhoon006 a écrit :



C’était sur OpenSSL qu’il y avait des soupçons de backdoor à un moment.

Et que le code avait était relu pour plein de monde.

Et personne a vu la faille à ce moment là…il a du être bien relu le code <img data-src=" />





Si tu lisait les info un peu mieux tu verrais que c’est sur une version relativement récente que le problème est apparue, Lors de la relecture cette “faille” n’existait pas encore <img data-src=" />



Et d’ailleurs c’est là tout le paradoxe, les vieux serveur pas mis à jours ne sont pas vulnérable <img data-src=" />









CoooolRaoul a écrit :



Quelqu’un aurait un lien vers une analyse bien didactique du truc?



De ce que j’ai lu jusqu’ici la faille permet de récupérer un bloc de 64k de données dont l’emplacement en mémoire m’a l’air non prévisible.

De la à récupérer comme c’est écrit comptes et mot de passe sur n’importe quel serveur web affecté il me semble qu’il y ait un peu de marge (mais je peux me tromper)







En gros le heartbeat consiste à envoyer un bloc de données qui est retourné par le serveur. La demande précise la taille du bloc (Un peu comme le header Content-Length de HTTP). L’erreur d’OpenSSL est de retourner depuis le serveur un volume correspondant au bloc demandé.

Si tu passes un bloc de 1 octet et que tu dis avoir envoyé 64ko (La taille de bloc max qui peut être paramétré), openSSL retourne… 64ko, soit ton octet, et tout ce qui traîne en mémoire derrière… D’où la fuite d’infos potentiellement critiques.



N.B.: C’est pas un bug introduit en 1.0.1 (Pas de méchant type de la NSA dessous)… C’est juste la première version à implémenter le heartbeat (Et une erreur triviale de développeur)









CoooolRaoul a écrit :



Quelqu’un aurait un lien vers une analyse bien didactique du truc?





Ça?







malock a écrit :



Hit : des trolls, il y en a autant chez les “pro-proprio” que chez les barbus jurant que par la ligne de commande… dingue !





C’est Hint pour conseil/astuce.









hadoken a écrit :



C’est fou la mauvaise foi quand même.



Quand on parle de code proprio tout de suite tout le monde nous tombe dessus “bouh les backdoors de la NSA”, “code buggé”, “privation de liberté”, “M$”, “FOSS = ton code sera relu = pas de faille”…etc.



Par contre quand un problème arrive sur une lib ultra connue en licence libre, personne n’a envie de voir en face le fait que les process de l’open source ne sont pas la silver bullet qui rend l’humanité meilleure à tous points de vue…



Prenez aussi la peine de regarder les liens fournis par 240-185 en page 3, c’est assez symptomatique de l’aveuglement des gourous du librisme.







Vous êtes censés être au dessus de tout ça. Mais la seule réaction que vous avez est d’être goguenard et de crier à la mauvaise foi.

C’est cool, on sait maintenant que vous aussi, vous savez jouer à la bagarre. Très constructif.



C’est terrible des deux côtés, le libre n’est pas THE solution et le code fermé engendre des problèmes de suivis régulièrement. C’est pas près de s’arrêter en plus.










hadoken a écrit :



C’est fou la mauvaise foi quand même.



Quand on parle de code proprio tout de suite tout le monde nous tombe dessus “bouh les backdoors de la NSA”, “code buggé”, “privation de liberté”, “M$”, “FOSS = ton code sera relu = pas de faille”…etc.



Par contre quand un problème arrive sur une lib ultra connue en licence libre, personne n’a envie de voir en face le fait que les process de l’open source ne sont pas la silver bullet qui rend l’humanité meilleure à tous points de vue…



Prenez aussi la peine de regarder les liens fournis par 240-185 en page 3, c’est assez symptomatique de l’aveuglement des gourous du librisme.





On en est où du patch pour le problème de rtf/outlook ?



C’est pour ça que j’ai eu des corrections au trot sur ma Mint hier soi et avant-hier soir…



Testé pour vous :







  • particuliers.societegeneral.fr : ça passe

  • materiel.net : ça passe

  • Amazon.fr : ça passe

  • ldlc.com : pas testable, prend pas le port 443










Impli a écrit :



Concernant le paragraphe sur l’identification.



Pourquoi ne pas envoyer le pass hashé au serveur qui se chargera de le hasher à nouveau, mais en incluant cette fois le salt.



De cette manière, le mot de pass n’est pas transmis en clair et le simple fait d’envoyer le hash “de base” ne valide pas l’identification.





C’est une méthode que j’utilisais il y a quelques temps. (En utilisant du SHA-2)





C’est une bonne solution, mais comme toutes les bonnes solutions, elle est sans doute rarement utilisée ;) C’est justement ce que je voulais souligner.



Par contre si la guerre libre / proprio qui ne sert à rien et qui n’est pas franchement à la hauteur du problème pouvait stopper. Ce serait pas mal. Merci. <img data-src=" />







Commentaire_supprime a écrit :



C’est pour ça que j’ai eu des corrections au trot sur ma Mint hier soi et avant-hier soir…



Testé pour vous :





Comme dit dans l’article, tester le domaine principal ce n’est pas regarder du bon côté.









Impli a écrit :



Concernant le paragraphe sur l’identification.



Pourquoi ne pas envoyer le pass hashé au serveur qui se chargera de le hasher à nouveau, mais en incluant cette fois le salt.





Ça ne change rien. Dans le cas de ce bug on récupérerait le hash du message avant le salt. Hors rien n’empêche un pirate d’envoyer le hash directement pour s’authentifier.



le plus top c’est que des boites concernées par la faille ne communique même pas en interne sur le sujet


Ce que j’en ai compris, c’est que c’est une bête erreur de conception sur une nouvelle version de la librairie qui sert de base à open SSL. C’est malheureusement un problème banal, et inévitable.



D’ailleurs, dans le domaine où je travaille, on en a de bons exemples de ce que ce genre de problème peut causer comme dommages…








typhoon006 a écrit :



C’était sur OpenSSL qu’il y avait des soupçons de backdoor à un moment.

Et que le code avait était relu pour plein de monde.

Et personne a vu la faille à ce moment là…il a du être bien relu le code <img data-src=" />





T’a des infos sur la version d’openSSL qui a été auditée ?







kypd a écrit :



Red Hat 6 est livré avec une version 1.0.0 qui n’est pas affectée…





Je savait bien que, contrairement à ce qui est dit ça et là RHEL n’est pas affecté. Le seul ‘ptit’ problème c’est que openSSL 1.0.1 apporte la faille, mais aussi une ÉNORME évolution dans le support du Perfect Forward Secrecy. Raison pour laquelle j’avais migré certains services… sur Debian <img data-src=" />



Ceux qui critiquent le comm de Hadoken n’ont pas du lire les commentaires sur les news “la nsa a approché Linus” ou celle sur GNUtls… Faut voir le nombre d’integriste qui t’insultent quand tu leur apprend que l’open source ne protège pas plus des failles… L’open source permet une grande réactivité mais c’est tout…

Mais bon si certains veulent continuer à vivre dans le pays des bisounours, tant mieux pour eux…








Khalev a écrit :



Ça ne change rien. Dans le cas de ce bug on récupérerait le hash du message avant le salt. Hors rien n’empêche un pirate d’envoyer le hash directement pour s’authentifier.







Certes, ça déporte seulement le problème en cas d’interception.

Les risques sont néanmoins limités que si le un pirate récupère le mot de pass en clair (impossible de pouvoir l’utiliser sur d’autres sites/comptes).



Et pour peu qu’on modifie légèrement le hash du pass, même en tentant une collision, ça n’apporterait rien.



Me trompe-je ?









Khalev a écrit :



C’est Hint pour conseil/astuce.







Absolument ! <img data-src=" />

Je “n” est passé à la trappe dans mon cerveau <img data-src=" />









jock a écrit :



il y a une bonne explication, ainsi que le code source ici







Ok merci, ca me conforte dans ce que je pensais: on n’a aucun controle sur ce qui est récupéré(“the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process.”, “the allocation patterns for pl are going to dictate what you can read”).



C’est donc bien au petit bonheur la chance et la possibilité de récupérer une clé privée est tres faible (“Heap allocation patterns make private key exposure unlikely for r #heartbleed)



Donc en résumé :




  • il y a une faille depuis une quasi-éternité, qui a pu être exploitée facilement

  • aucune vision des sites corrigés qui ont été touchés ou pas



    Ca fait que globalement toute donnée sensible a pu être corrompue sur un site “sécurisé”… génial <img data-src=" />








jock a écrit :



il y a une bonne explication, ainsi que le code source ici









Ok merci, ca me conforte dans ce que je pensais: on n’a aucun controle sur ce qui est récupéré(“the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process.”, “the allocation patterns for pl are going to dictate what you can read”).



C’est donc bien au petit bonheur la chance et la possibilité de récupérer une clé privée est tres faible (“Heap allocation patterns make private key exposure unlikely for #heartbleed”)









CoooolRaoul a écrit :



Quelqu’un aurait un lien vers une analyse bien didactique du truc?



De ce que j’ai lu jusqu’ici la faille permet de récupérer un bloc de 64k de données dont l’emplacement en mémoire m’a l’air non prévisible.

De la à récupérer comme c’est écrit comptes et mot de passe sur n’importe quel serveur web affecté il me semble qu’il y ait un peu de marge (mais je peux me tromper)







Ce n’est effectivement pas prévisible, mais 64 ko ce n’est pas rien et on récupère assez facilement des données sensibles : login, mail, mot de passe, ainsi que nom du magasin et montant de la transaction pour les achats en ligne, etc.









sylvere a écrit :



et qui deviendront “consultant senior” à la fin de leur sta… heu… à la fin de leur première expérience de 6 mois… heu… de 3 ans





C’est pas une raison pour demander une augmentation.









hadoken a écrit :



C’est fou la mauvaise foi quand même.



Quand on parle de code proprio tout de suite tout le monde nous tombe dessus “bouh les backdoors de la NSA”, “code buggé”, “privation de liberté”, “M$”, “FOSS = ton code sera relu = pas de faille”…etc.



Par contre quand un problème arrive sur une lib ultra connue en licence libre, personne n’a envie de voir en face le fait que les process de l’open source ne sont pas la silver bullet qui rend l’humanité meilleure à tous points de vue…



Prenez aussi la peine de regarder les liens fournis par 240-185 en page 3, c’est assez symptomatique de l’aveuglement des gourous du librisme.





Indice :



Quelqu’un qui dit que le libre est bullet-proof, c’est un troll. Soit tu lui réponds, soit tu l’ignores, mais de toute façon il a tort.



Les développeurs de ces logiciels libres savent très bien que leur code n’est pas à toute épreuve, ils n’ont jamais prétendu que leur code était invulnérable.



Apprends donc à distinguer les trolls des vrais libristes. Faut arrêter de vouloir mettre tout le monde dans le même panier, ça devient fatiguant de ré-entendre toujours ces mêmes poncifs à la fin.









CoooolRaoul a écrit :



Ok merci, ca me conforte dans ce que je pensais: on n’a aucun controle sur ce qui est récupéré(“the read from memcpy is going to read whatever memory was near the SSLv3 record and within the same process.”, “the allocation patterns for pl are going to dictate what you can read”).



C’est donc bien au petit bonheur la chance et la possibilité de récupérer une clé privée est tres faible (“Heap allocation patterns make private key exposure unlikely for r #heartbleed)





Pour les éléments tels que la clef privée, oui, je n’ai pas trouvé de cas qui l’évoque clairement. Par contre récupérer des données comme les login / pass & co, c’est assez facile puisque certains serveurs ne servent qu’à faire de l’authentification par exemple. Et là…



<img data-src=" /> Merci Hadoken et Charon pour cette grosse tranche de rigolade à voir des barbus hurler en ayant mal au cul. <img data-src=" />








Konrad a écrit :



Indice :



Quelqu’un qui dit que le libre est bullet-proof, c’est un troll. Soit tu lui réponds, soit tu l’ignores, mais de toute façon il a tort.



Les développeurs de ces logiciels libres savent très bien que leur code n’est pas à toute épreuve, ils n’ont jamais prétendu que leur code était invulnérable.



Apprends donc à distinguer les trolls des vrais libristes. Faut arrêter de vouloir mettre tout le monde dans le même panier, ça devient fatiguant de ré-entendre toujours ces mêmes poncifs à la fin.







<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



TOUT est vulnérable RIEN n’est bullet-proof, peu importe la licence.



Le libre, c’est faire un pari sur la réactivité de la communauté en cas de pépin.



Le proprio, c’est faire un pari sur le professionnalisme du détenteur des droits sur le code en cas de pépin.



Après, à vous de voir. Le reste n’est que troll de bas étage.









peij a écrit :



Le gros avantage de l’open-source en soit n’est pas le fait qu’il n’y a pas de failles, c’est évident.



Par contre, et on en a encore un bel exemple ici, lorsqu’une faille est découverte, elle est généralement corrigé dans les heures qui suivent, et tout est mis à jour, au niveau des dépôts, très rapidement.







La faille a été introduite en 2012, d’autres personnes mal intentionnées l’ont peut-être découverte et l’utilisent depuis 2 ans.





Ici, la faille a été corrigée avant d’être divulguée, et c’est ça, la grande force de l’open-source versus le proprio.



<img data-src=" />

Regarde tous les bulletins de sécurité des softs proprio, et tu verras que l’énorme majorité des failles corrigées (que ce soit dans le libre ou dans le proprio) le sont avant leur divulgation. Ça n’a RIEN à voir avec le fait d’être open-source ou pas. J’ai du mal à comprendre comment un développeur (que tu es) peut avoir un raisonnement aussi faux.



Inversement, il y a régulièrement des 0-day concernant des softs libres.





Je ne suis pas contre le proprio, j’en utilise tous les jours (je développe en .net), mais clairement, ici, il s’agit d’un net avantage.





cf ci-dessus, ça n’a absoluement rien à voir.









Konrad a écrit :



Indice :



Quelqu’un qui dit que le libre est bullet-proof, c’est un troll. Soit tu lui réponds, soit tu l’ignores, mais de toute façon il a tort.



Les développeurs de ces logiciels libres savent très bien que leur code n’est pas à toute épreuve, ils n’ont jamais prétendu que leur code était invulnérable.



Apprends donc à distinguer les trolls des vrais libristes. Faut arrêter de vouloir mettre tout le monde dans le même panier, ça devient fatiguant de ré-entendre toujours ces mêmes poncifs à la fin.





Tu as lu la réponse du responsable de la FSF ? (liens en page 3)



Parler de Microsoft et du Mal qu’est le propriétaire pour commenter une faille d’OpenSSL faut y aller quand même…









gathor a écrit :



Ce n’est effectivement pas prévisible, mais 64 ko ce n’est pas rien et on récupère assez facilement des données sensibles : login, mail, mot de passe, ainsi que nom du magasin et montant de la transaction pour les achats en ligne, etc.







Oui, enfin ça reste quand même aléatoire: un échantillon de 64K sur l’ensemble de la mémoire d’un serveur web qui se compte souvent en centaines de mégas ca s’apparente quand même un peu à de la pèche (et ne pas oublier que c’est limité à la heap du thread en cours: si c’est pour récupérer son propre mot de passe nous voila bien avancés).

Bien sur, Je ne dis pas qu’il ne faut pas s’inquiéter mais récupérer des infos utilisables est plus une question de chance que de compétence.



Je vient de mettre mon raspberry pi sous raspbian à jour <img data-src=" />



(la version d’openssl était apparement vulnérable)








Commentaire_supprime a écrit :



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



TOUT est vulnérable RIEN n’est bullet-proof, peu importe la licence.



Le libre, c’est faire un pari sur la réactivité de la communauté en cas de pépin.



Le proprio, c’est faire un pari sur le professionnalisme du détenteur des droits sur le code en cas de pépin.



Après, à vous de voir. Le reste n’est que troll de bas étage.







<img data-src=" />









CoooolRaoul a écrit :



Oui, enfin ça reste quand même aléatoire: un échantillon de 64K sur l’ensemble de la mémoire d’un serveur web qui se compte souvent en centaines de mégas ca s’apparente quand même un peu à de la pèche (et ne pas oublier que c’est limité à la heap du thread en cours: si c’est pour récupérer son propre mot de passe nous voila bien avancés).

Bien sur, Je ne dis pas qu’il ne faut pas s’inquiéter mais récupérer des infos utilisables est plus une question de chance que de compétence.







C’est peut-être une question de chance, mais dans ce cas, il suffit de multiplier les tentatives, ce qui n’est pas compliqué en informatique.









Freud a écrit :



La faille a été introduite en 2012, d’autres personnes mal intentionnées l’ont peut-être découverte et l’utilisent depuis 2 ans.





C’est un peu le principe d’une faille, hein ?










CoooolRaoul a écrit :



Oui, enfin ça reste quand même aléatoire: un échantillon de 64K sur l’ensemble de la mémoire d’un serveur web qui se compte souvent en centaines de mégas ca s’apparente quand même un peu à de la pèche (et ne pas oublier que c’est limité à la heap du thread en cours: si c’est pour récupérer son propre mot de passe nous voila bien avancés).

Bien sur, Je ne dis pas qu’il ne faut pas s’inquiéter mais récupérer des infos utilisables est plus une question de chance que de compétence.







La possibilité étant non-nulle et le risque possible conséquent, ce fait doit quand même être pris en compte.



La sécurité, c’est une attitude permanente, pas l’utilisation d’outils miraculeux qui ne peuvent pas exister, peu importe le langage, la licence, le code…









CoooolRaoul a écrit :



Oui, enfin ça reste quand même aléatoire: un échantillon de 64K sur l’ensemble de la mémoire d’un serveur web qui se compte souvent en centaines de mégas ca s’apparente quand même un peu à de la pèche (et ne pas oublier que c’est limité à la heap du thread en cours: si c’est pour récupérer son propre mot de passe nous voila bien avancés).

Bien sur, Je ne dis pas qu’il ne faut pas s’inquiéter mais récupérer des infos utilisables est plus une question de chance que de compétence.







si bien compris le truc les 64k entoure les quelques octets que l’extension Heartbeat demande et je doute fort que les quelques octets là soit bien éloigné en mémoire des info de connexion/clé et autres

donc oui 64k c’est peu mais bien remplis des bonnes infos c’est énorme









hadoken a écrit :



Tu as lu la réponse du responsable de la FSF ? (liens en page 3)



Parler de Microsoft et du Mal qu’est le propriétaire pour commenter une faille d’OpenSSL faut y aller quand même…





Si tu savais sur quoi je bosse en ce moment et comment est gérée la com au niveau des clients tu verrais à quel point le proprio c’est mal



Après que des boites proprio aient d’excellentes réactions et gestion de communication de crises et que des projets libres soient gérées par des pignoufs qui pètent plus haut que leur cul c’est effectivement le cas.



Perso je me pose plus des questions sur les process de conceptions et validations pour tout ce qui touche à la sécurité que sur le bien-fondé du libre vs proprio…



L’humain étant faillible, toutes ses créations le sont.



Et son génie consiste justement à sublimer sa faillibilité.



C’est ce qui pour moi est le plus intéressant dans cette histoire de sécurité informatique.



“Il y a une faille en tout, c’est comme cela que la lumière rentre” - Leonard COHEN








hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />





<img data-src=" />



Tout ce que permet le libre, c’est que si quelqu’un détecte une faille, tout le monde peut la remonter dans le code source, voir ses causes, la corriger ou vérifier sa correction. S’il y avait eu un commentaire “NSA backd00r”, on l’aurait vu. Alors qu’avec le proprio, c’est moins sûr.



Et auditer le code ne prouve pas l’absence de code (prouver le code, oui, et encore).









Khalev a écrit :



Si tu savais sur quoi je bosse en ce moment et comment est gérée la com au niveau des clients tu verrais à quel point le proprio c’est mal



Après que des boites proprio aient d’excellentes réactions et gestion de communication de crises et que des projets libres soient gérées par des pignoufs qui pètent plus haut que leur cul c’est effectivement le cas.



Perso je me pose plus des questions sur les process de conceptions et validations pour tout ce qui touche à la sécurité que sur le bien-fondé du libre vs proprio…





C’est pas faux.



Je bosse actuellement sur un logiciel proprio, et on a un service de sécurité qui s’est occupé de tester l’engin pour détecter les failles de sécurité, qui ont toutes été corrigées immédiatement par l’éditeur.



Et quelques semaines après, un SSO a été implanté sur le tomcat de l’appli avec une librairie libre qui utilise une authentification NTLM V1…..









ActionFighter a écrit :



Et je ne pense pas que ce soit une “tanche”, seulement son anti-fanboysbarbus commence à l’aveugler un peu trop.





Surtout que l’on sait très bien que les fanboys dont ils parlent sont en fait des fanboys du proprio qui disent des bêtises en ce faisant passer pour des fanboys du libre.



Bon je retourne à mes majs, les blagues d’hier on failli me faire rater la mise à jour dehttp://technet.microsoft.com/en-us/security/advisory/2953095 que j’attendais avec impatience (j’en profite au cas où d’autre serait aussi passer à côté hier).



Pour contribuer au débat, on peut remarquer, c’est que le code managé proprio ne protège pas contre les hackers qui ont 5 ans. <img data-src=" />








TaigaIV a écrit :



Surtout que l’on sait très bien que les fanboys dont ils parlent sont en fait des fanboys du proprio qui disent des bêtises en ce faisant passer pour des fanboys du libre.





C’est fort possible en effet…







TaigaIV a écrit :



Bon je retourne à mes majs, les blagues d’hier on failli me faire rater la mise à jour dehttp://technet.microsoft.com/en-us/security/advisory/2953095 que j’attendais avec impatience (j’en profite au cas où d’autre serait aussi passer à côté hier).





Fallait cloner le git si t’es pas content de leur temps de réaction <img data-src=" />









TaigaIV a écrit :



Surtout que l’on sait très bien que les fanboys dont ils parlent sont en fait des fanboys du proprio qui disent des bêtises en ce faisant passer pour des fanboys du libre.



Bon je retourne à mes majs, les blagues d’hier on failli me faire rater la mise à jour dehttp://technet.microsoft.com/en-us/security/advisory/2953095 que j’attendais avec impatience (j’en profite au cas où d’autre serait aussi passer à côté hier).





Tout ça c’est un coup de MS pour faire passer leur màj discretos en fait <img data-src=" />









Jarodd a écrit :



La version bugguée date de 2012, et on coupe les sites depuis hier ? <img data-src=" />



On sait de qui est sortie l’info de cette faille ? Qui l’a dévoilé, et quand exactement ? Ca a été corrigé avant ou après la divulgation ?





Oui, je comprends pas bien, pourquoi on parle de risque pour les connections des 2 derniers jours alors que c’est vulnérable depuis 2 ans.

Des pirates peuvent avoir tout pompé depuis 2 ans sans avertir personne non ?

Il ne faudrait pas de toute façons changer tous ses mots de passe ?

J’ai des comptes hotmail/outlook, je dois changer mes mdp ?

(dsl si ça a déjà été posé, la flemme de lire tous les commentaires <img data-src=" />)



Une faille découverte sur un logiciel utilisé par la moitié des sites web, la moitié rien que ça.



les pirates peuvent récupérer des informations en passant par la mémoire des serveurs de l’ordinateur



<img data-src=" /><img data-src=" /><img data-src=" />








hadoken a écrit :



C’est fou la mauvaise foi quand même.



Quand on parle de code proprio tout de suite tout le monde nous tombe dessus “bouh les backdoors de la NSA”, “code buggé”, “privation de liberté”, “M$”, “FOSS = ton code sera relu = pas de faille”…etc.



Par contre quand un problème arrive sur une lib ultra connue en licence libre, personne n’a envie de voir en face le fait que les process de l’open source ne sont pas la silver bullet qui rend l’humanité meilleure à tous points de vue…



Prenez aussi la peine de regarder les liens fournis par 240-185 en page 3, c’est assez symptomatique de l’aveuglement des gourous du librisme.







SI tu parles de ce lien:



240-185 a écrit :



La FSF



Et ils se défaussent en disant que le bug a été corrigé grâce à l’ouverture du code, tout en passant en silence le fait qu’il a quand même fallu deux ans pour le découvrir : http://www.fsf.org/news/free-software-foundation-statement-on-heartbleed-vulnerability







Soyons fou, je vais essayer de traduire correctement le billet pour les non-anglophones, car je crois qu’il y a là un certain détournement qui est fait du propos initial, que je trouve très juste.



[quote:FSF]

Utiliser du logiciel libre, comme OpenSSL, est une première étape nécessaire à la sécurisation de nos ordinateurs, serveurs, ainsi qu’à celle de tout l’Internet. Les logiciels libres apportent la garantie aux utilisateurs qu’ils ont la possibilité d’accéder au code source afin de détecter des failles, et de créer de nouvelles versions corrigées lorsqu’un bug est découvert. Les bugs, qui sont parfois gros et touchant des logiciels extrêmement courants comme Heartbleed pour OpenSSL, peuvent survenir dans n’importe quel code, libre comme propriétaire. La différence est que lorsque les sources ne sont accessibles qu’à la compagnie qui les détient, comme par exemple Microsoft, et que seule cette dernière a le pouvoir de corriger les éventuels défauts, il est impossible d’avoir une vraie chaîne de confiance [NdT: entre la compagnie et l’utilisateur final]. Tout le monde est alors sans défense tant que Microsoft ne décide d’agir.



Il a été rapporté que des compagnies comme Microsoft partagent volontairement des bugs sans les corriger avec d’autres entités comme la NSA, faisant mine de n’avoir rien vu afin que ces tierces partiespuissent exploiter les failles de sécurité. Et Apple a un backdoor sur iPhone qui selon des experts de la sécurité a été implémenté soit par la NSA, soit dans le cadre d’un sabotage interne chez Apple. En bref, les exemples d’insécurité dans le logiciel propriétaire abondent.



Heartbleed est une faille de sécurité critique, et c’est une bonne chance que OpenSSL soit un logiciel libre. Cela a permis au bug d’être identifié, et corrigé rapidement après sa découverte.[/quote]





Les process de l’open source n’ont bien sûr jamais garanti le 0 faille, qui n’existe de toute façon pas en informatique (comme ça c’est dit au moins :P). Et la FSF ne se dédouane pas d’avoir laissé filer un bug dans leur logiciel, ni même que cela ait pris 2 ans à le trouver. Ce qu’ils disent, c’est que parce que le logiciel est libre, les actions suivantes ont pu être menées à bien:




  • un googler a pu se pencher sur le code afin de détecter le défaut

  • la communauté n’était pas pieds et poings liés à attendre un éventuel patch (comme cité plus haut, rien n’empêche de recompiler OpenSSL sans HeartBeat)

  • le défaut a été corrigé rapidement, ce qui est visible aux yeux de tous dans le repository



    Qu’il ait fallu 2 ans pour tomber sur ce bug est je pense complètement anecdotique et hors propos: des bugs, il y en a, et tant qu’on ne met pas le doigt dedans, on ne les voit pas (je parle de “vrais bugs vicieux”, pas de segfault). Sur de tels logiciels, on ne peut ni tester ni même imaginer tous les cas de robustesse et cas non fonctionnels, c’est à l’utilisation que l’on détecte et corrige les défauts au fil de l’eau.

    Ca existe depuis fin 1998 tout de même, et les gros bugs critiques détectés dans OpenSSL se comptent sur les doigts d’une main estropiée de 2 ou 3 doigts… Peut-on en dire autant des logiciels propriétaires ? Si on prend l’exemple de IE6, qui avec ses 80% de part de marché à la belle époque, son nombre de bugs ouverts en parallèle relativement violent, et les délais pour attendre les correctif, le moins que l’on puisse faire est de tourner 7 son clavier avant de commencer à écrire.









Soltek a écrit :



Une faille découverte sur un logiciel utilisé par la moitié des sites web, la moitié rien que ça.



<img data-src=" /><img data-src=" /><img data-src=" />





Cela peut prêter à sourire, à part si l’article parle de serveur au sens software et non hardware, ce dont je doute.



edit : en fait non, c’est con dans tout les cas puisqu’en parlant de mémoire du serveur, il considère le serveur comme hardware <img data-src=" />



Par contre, je n’avais non plus pensé à cela, mais TOR, qui est cité dans l’article, est devenu totalement vulnérable, surtout dans le cas des bundles qui embarquent une version d’openSSL.









le podoclaste a écrit :



C’est peut-être une question de chance, mais dans ce cas, il suffit de multiplier les tentatives, ce qui n’est pas compliqué en informatique.







Et on récupérera les mêmes données vu que la map des variables dans la pile n’aura pas changé entre les différents essais (à moins de modif et recompilation du code entre temps).

Ne pas oublier qu’il s’agit de code C et, je viens de vérifier, il s’agit de données de la stack qu’on récupère (pas de la heap), par suite les variables dont le contenu est récupéré sont bien les mêmes à chaque fois.









Commentaire_supprime a écrit :





  • ldlc.com : pas testable, prend pas le port 443





    secure.ldlc.com : ça passe



Un code source dispo et bien exploité ne permettrait pas d’orienter ses attaques et/ou de mieux détecter les failles ? <img data-src=" />








ActionFighter a écrit :



Il parlait de moi, donc je répond.



Et je ne pense pas que ce soit une “tanche”, seulement son anti-fanboysbarbus commence à l’aveugler un peu trop.







Tu es trop bon <img data-src=" />



Enfin, il en faut bien pour faire l’effort de compréhension dont certains se passent j’imagine.









240-185 a écrit :



La FSF



Et ils se défaussent en disant que le bug a été corrigé grâce à l’ouverture du code, tout en passant en silence le fait qu’il a quand même fallu deux ans pour le découvrir : http://www.fsf.org/news/free-software-foundation-statement-on-heartbleed-vulnerability







La différence c’est qu’avec le libre tu peux savoir exactement depuis quand, alors qu’avec du proprio, même si ça fait 6 mois ou 10 ans, c’est beaucoup plus compliqué, vu qu’il faut tester touts les binaires un par un.









Commentaire_supprime a écrit :



La possibilité étant non-nulle et le risque possible conséquent, ce fait doit quand même être pris en compte.

La sécurité, c’est une attitude permanente, pas l’utilisation d’outils miraculeux qui ne peuvent pas exister, peu importe le langage, la licence, le code…





Moi qui pensait que la prière et l’espoir préservaient des force démoniaques de la piraterie sauvage, me voila bien désabusé… <img data-src=" />









Munsh a écrit :



Tu es trop bon <img data-src=" />





Mes sujets n’arrêtent pas de me le dire <img data-src=" />









Ricard a écrit :



Heu…64ko de données non chifrées, c’est énorme.<img data-src=" />





Mon mot de passe fait plus de 64k, pas de problème <img data-src=" />



(ou pas <img data-src=" /> )









zefling a écrit :



La différence c’est qu’avec le libre tu peux savoir exactement depuis quand, alors qu’avec du proprio, même si ça fait 6 mois ou 10 ans, c’est beaucoup plus compliqué, vu qu’il faut tester touts les binaires un par un.





Heu… ou alors en demandant à l’éditeur.









tiny_naxos a écrit :



Un code source dispo et bien exploité ne permettrait pas d’orienter ses attaques et/ou de mieux détecter les failles ? <img data-src=" />





Bien exploité c.a.d. le pirate insère directement ses failles via des contributions communeautaires? <img data-src=" />









Soltek a écrit :



Une faille découverte sur un logiciel utilisé par la moitié des sites web, la moitié rien que ça.



<img data-src=" /><img data-src=" /><img data-src=" />





wow.

déjà que l’article du monde était limite, là sur le point on sent la grosse compétence de l’auteur. <img data-src=" />



Quel bazar ! <img data-src=" />



Quelqu’un a posé la question mais je n’ai pas vu la réponse : pour les comptes Google (gmail…), Facebook, Hotmail, … faut-il changer de mot de passe ? (sans doute vaut-il mieux …)

Merci








yvan a écrit :



Bien exploité c.a.d. le pirate insère directement ses failles via des contributions communeautaires? <img data-src=" />





Non, bien relu…









Cypus34 a écrit :



Oui, je comprends pas bien, pourquoi on parle de risque pour les connections des 2 derniers jours alors que c’est vulnérable depuis 2 ans.

Des pirates peuvent avoir tout pompé depuis 2 ans sans avertir personne non ?

Il ne faudrait pas de toute façons changer tous ses mots de passe ?

J’ai des comptes hotmail/outlook, je dois changer mes mdp ?

(dsl si ça a déjà été posé, la flemme de lire tous les commentaires <img data-src=" />)



La faille a été révélée publiquement il y a 2 jours.

Effectivement, des pirates pouvaient avoir connaissance de la faille depuis plus longtemps mais ils restent moins nombreux que les script-kiddies de ces derniers jours qui ont dû récupérer quelques paquets de 64kio sur des serveurs vulnérables (genre yahoo qui a visiblement été bien attaqué) et donc beaucoup de paire login/mot de passe.



Actions pour le service :




  • Révoquer les anciens certificats (oui, on coupe le service à ce niveau).

  • Mettre à jour OpenSSL si nécessaire (que ce soit vers la 1.0.1g ou en désactivant Heartbeat-TLS sur la version 1.0.1* en cours, même si la première solution est préférable).

  • Mettre à jour les certificats du service.

  • Relancer le service

  • Avertir ses utilisateurs et invalider tous les mot de passe (éventuellement autoriser une connexion avec modif du mot de passe obligatoire).





    Comment réduire les risques pour l’utilisateur :

  • Attendre que le service touché soit corrigé (et ne pas se connecter pour ne pas mettre ses identifiants dans la RAM du serveur).

  • Une fois le service corrigé (s’assurer que toutes les changements ci-dessus ont été effectuées), changer de mot de passe.













Soltek a écrit :



Une faille découverte sur un logiciel utilisé par la moitié des sites web, la moitié rien que ça.



<img data-src=" /><img data-src=" /><img data-src=" />





C’est clair que ce qu’il écrit ne veut rien dire, mais techniquement c’est vrai.

OpenSSL est presque partout dans les serveurs TLS.





Nous avons par exemple contacté Slate hier pour leur indiquer suite à leur article qu’ils étaient eux-mêmes touchés, mais ils nous ont confirmé qu’ils n’utilisaient pas OpenSSL dans la pratique.

Comment peuvent-ils être touchés sans utiliser OpenSSL ? <img data-src=" />

Ou alors, HTTPS est dispo sur leur site mais ça ne change rien parce qu’il n’y a pas de comptes utilisateurs et donc pas de login en RAM.


Je me pose une question quand même.



Les 64 Ko de mémoire renvoyé par le serveur est aléatoire. Comment ça se fait que dans le cas de Yahoo! , le serveur renvoie souvent des login et mot de passe ?



Le nombre d’authentification ? L’implémentation de Yahoo! de la gestion de leur authentification ?








yvan a écrit :



Heu… ou alors en demandant à l’éditeur.







Oui, mais il faut alors attendre sa réponse, si il a bien envie de la donner. Tu ne peux rien faire seul.









Cypus34 a écrit :



Oui, je comprends pas bien, pourquoi on parle de risque pour les connections des 2 derniers jours alors que c’est vulnérable depuis 2 ans.

Des pirates peuvent avoir tout pompé depuis 2 ans sans avertir personne non ?

Il ne faudrait pas de toute façons changer tous ses mots de passe ?

J’ai des comptes hotmail/outlook, je dois changer mes mdp ?

(dsl si ça a déjà été posé, la flemme de lire tous les commentaires <img data-src=" />)





Le risque existe dans les deux cas, mais c’est surtout depuis l’officialisation que les sites vulnérables peuvent être visités par n’importe qui ou presque. Il a donc été démultiplié d’autant.









GentooUser a écrit :



Je savait bien que, contrairement à ce qui est dit ça et là RHEL n’est pas affecté.





Si, RHEL est impactée, mais seulement les versions à jours (RHEL 6.5). Je crois que c’est ce qu’on appelle l’ironie du sort ^^

https://lwn.net/Articles/593840/









zefling a écrit :



Oui, mais il faut alors attendre sa réponse, si il a bien envie de la donner. Tu ne peux rien faire seul.





Sur ce genre de problématiques, à moins de ne pas savoir signer de contrat la réponse c’est H+4 (H+2 et sinon tu appelles le commercial et c’est H+2 x2 <img data-src=" /> )



Libre comme propriétaire il faut avoir de bons fournisseurs.









lecbee a écrit :



Si, RHEL est impactée, mais seulement les versions à jours (RHEL 6.5). Je crois que c’est ce qu’on appelle l’ironie du sort ^^

https://lwn.net/Articles/593840/





Je vient de voir aussi, l’évolution majeure de RHEL 6.5 : le passage à OpenSSL 1.0.1 <img data-src=" /> C’est d’ailleurs contraire à la pratique de RedHat au passage et a dû être motivé par le retard pris par RHEL 7 ?



EDIT: Linuxfr dit que la cause est le rachat de Glusterfs.



Bon déjà c’est pas parce que la faille à deux ans qu’on est exposé depuis ce temps, RHEL est concerné depuis Novembre et Debian depuis pile un an.



Merci pour les explications, et surtout merci d’utiliser votre position de journalistes spécialisés pour contribuer à faire passer le message le plus largement et rapidement possible.



<img data-src=" />








ben5757 a écrit :



Je me pose une question quand même.



Les 64 Ko de mémoire renvoyé par le serveur est aléatoire. Comment ça se fait que dans le cas de Yahoo! , le serveur renvoie souvent des login et mot de passe ?



Le nombre d’authentification ? L’implémentation de Yahoo! de la gestion de leur authentification ?





Ils ont peut-être un serveur dédié uniquement à l’authentification via openssl. Du coup tout ce que traite le serveur c’est des logins et mot de passe donc la mémoire en est pleine.









Vieux_Coyote a écrit :



Quel bazar ! <img data-src=" />



Quelqu’un a posé la question mais je n’ai pas vu la réponse : pour les comptes Google (gmail…), Facebook, Hotmail, … faut-il changer de mot de passe ? (sans doute vaut-il mieux …)

Merci





Dans le doute, oui il vaut mieux. On ne sait pas si la faille n’était pas exploitée avant ça, si c’est le cas surement que des trucs ont pu fuiter de google & co.









hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />







Il n’y a personne dans le monde de libre qui a sorti cela un jour. Ce qui a été dit c’est que le libre permet une grande transparence du code et une très grande réactivité à la découverte de faille et pour les boucher. <img data-src=" />









yvan a écrit :



Sur ce genre de problématiques, à moins de ne pas savoir signer de contrat la réponse c’est H+4 (H+2 et sinon tu appelles le commercial et c’est H+2 x2 <img data-src=" /> )



Libre comme propriétaire il faut avoir de bons fournisseurs.







Ouais, enfin ça reste que dans un professionnel et espérant que ton contrat te permette ça. Bref, pour les petites boîtes qui n’ont pas le moyen de payer un tel service : au revoir. Et il faut espérer qu’en face la société qui a le logiciel soit H24 77 et que tu tombes pas quand t’as la moitié des dév en vacances (genre en août ou à Noël)… Puis pour finir, si t’as la chance d’être un particulier ce genre de service. <img data-src=" />









Soltek a écrit :



Une faille découverte sur un logiciel utilisé par la moitié des sites web, la moitié rien que ça.



<img data-src=" /><img data-src=" /><img data-src=" />





“la mémoire des serveurs de l’ordinateur”

Haha putin j’ai explosé. <img data-src=" />

Bon après dans l’ensemble y’a pas d’énormes conneries.









hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />









http://www.pcinpact.com/news/55058-windows-faille-17-ans-nt-ntvdm-bulletin.htm



“Petite polémique autour d’une faille sur laquelle Microsoft vient de communiquer. Le trait particulier de cette faille est qu’elle a un âge plutôt vénérable : 17 ans”



Le closed source dans toute sa splendeur. <img data-src=" />





Parfois c’est difficile de pas feed. <img data-src=" />









zefling a écrit :



Ouais, enfin ça reste que dans un professionnel et espérant que ton contrat te permette ça. Bref, pour les petites boîtes qui n’ont pas le moyen de payer un tel service : au revoir. Et il faut espérer qu’en face la société qui a le logiciel soit H24 77 et que tu tombes pas quand t’as la moitié des dév en vacances (genre en août ou à Noël)… Puis pour finir, si t’as la chance d’être un particulier ce genre de service. <img data-src=" />





SI tu es une petite boite tu passes des contrats d’infogérance avec les sociétés qui ont suffisamment de poids pour obtenir les réponses dans les temps.

Je doute qu’un OVH, un akamai ou un Amen attende longtemps des réponse de ses éditeurs système concernant la sécurité par ex.









TriEdge a écrit :



http://www.pcinpact.com/news/55058-windows-faille-17-ans-nt-ntvdm-bulletin.htm



“Petite polémique autour d’une faille sur laquelle Microsoft vient de communiquer. Le trait particulier de cette faille est qu’elle a un âge plutôt vénérable : 17 ans”



Le closed source dans toute sa splendeur. <img data-src=" />





Parfois c’est difficile de pas feed. <img data-src=" />







Et quand un mec se classe parmi les meilleurs joueurs d’échec du monde dès l’âge de 17 ans, tu retournes jouer aux billes ?









yvan a écrit :



SI tu es une petite boite tu passes des contrats d’infogérance avec les sociétés qui ont suffisamment de poids pour obtenir les réponses dans les temps.

Je doute qu’un OVH, un akamai ou un Amen attende longtemps des réponse de ses éditeurs système concernant la sécurité par ex.





Par contre, c’est pas dit que t’es la réponse d’OVH dans les 2 heures… Puis vos voir comment son traités les petits par ses groupes. <img data-src=" />









GentooUser a écrit :



Je vient de voir aussi, l’évolution majeure de RHEL 6.5 : le passage à OpenSSL 1.0.1 <img data-src=" /> C’est d’ailleurs contraire à la pratique de RedHat au passage et a dû être motivé par le retard pris par RHEL 7 ?



EDIT: Linuxfr dit que la cause est le rachat de Glusterfs.





Je ne sais pas ce qui a motivé la mise à jour de version d’OpenSSL, mais il y a régulièrement des mises à jours importantes des paquets même dans les versions intermédiaires (exemple passage de samba 3.5 à 3.6 entre RHEL 6.3 et 6.4).



Pour ce qui est de RHEL7, je ne pense pas qu’elle prenne spécialement du retard. Il faut voir aussi que RH apporte 13 ans de support pour RHEL5 et 6, donc s’ils sortent trop rapidement des nouvelles versions majeures, ça va leur faire beaucoup de support à faire ! RHEL4 est encore supporté jusqu’à début 2015…



Très bonne news par contre ça serait bien que y’ai une partie un peu moins grand public et que PCInpact sorte du lot de l’info numérique en expliquant concrètement le fonctionnement de la faille.


Faille présente sur le DSM 5.0 de Synologiy qui ne communique pas sur les failles non corrigées (!) :



Pour protéger les utilisateurs, Synology n’annonce pas publiquement les vulnérabilités de la sécurité jusqu’à ce que les résolutions soient publiquement disponibles ni les détails exacts de l’émission de telles vulnérabilités. Une fois que les résolutions sont disponibles, les vulnérabilités seront annoncées sur le site web officiel de Synology.



Comme si dans le cas présent, cela servait à quelque chose de ne pas communiquer là dessus !



À l’équipe : avec vos contacts privilégiés chez eux, vous pouvez avoir une info sur la date de correction ?








coolraoul a écrit :



Très bonne news par contre ça serait bien que y’ai une partie un peu moins grand public et que PCInpact sorte du lot de l’info numérique en expliquant concrètement le fonctionnement de la faille.





Si tu es technique et anglophone :http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html









fred42 a écrit :



Faille présente sur le DSM 5.0 de Synologiy qui ne communique pas sur les failles non corrigées (!) :



Comme si dans le cas présent, cela servait à quelque chose de ne pas communiquer là dessus !



À l’équipe : avec vos contacts privilégiés chez eux, vous pouvez avoir une info sur la date de correction ?







C’est vrai que cette attitude est un peu décevante. Au moins savoir permets à l’utilisateur de prendre action.









fred42 a écrit :



Faille présente sur le DSM 5.0 de Synologiy qui ne communique pas sur les failles non corrigées (!) :



Comme si dans le cas présent, cela servait à quelque chose de ne pas communiquer là dessus !



À l’équipe : avec vos contacts privilégiés chez eux, vous pouvez avoir une info sur la date de correction ?







De toutes façons, c’est pour les systèmes embarqués que ça va saigner le plus car certains constructeurs n’auront peut-être pas prévu de méthode de mise à jour de leurs produits, et d’autres auront juste la flemme….









Impli a écrit :



Et pour peu qu’on modifie légèrement le hash du pass, même en tentant une collision, ça n’apporterait rien.



Me trompe-je ?







Oui :)



Le hash d’une chaîne de caractère par une fonction de hash donnée est toujours le même. Si tu changes le hash c’est que tu as changé une donnée (le mdp, un sel) que le serveur ne connaîtra pas. Il ne pourra donc pas d’identifier…



Tor est touché aussi et il recommandé de ne pas l’utiliser pour l’instant








Vser a écrit :



Oui :)



Le hash d’une chaîne de caractère par une fonction de hash donnée est toujours le même. Si tu changes le hash c’est que tu as changé une donnée (le mdp, un sel) que le serveur ne connaîtra pas. Il ne pourra donc pas d’identifier…







J’ai du mal m’exprimer.



Quand je parle de modifier le hash, je parle de modifier légèrement le hash que l’on enverrai au serveur de façon à ce que si le hash est cassé, le pirate ne récupère pas le vrai mot de pass.

Après oui, le hash est toujours le même pour un pass donné. Mais là n’est pas là question.



Et si, le serveur reconnaîtra. Puisque, bien sûr, on ajoute le salt sur le hash modifié.

Au final la comparaison reste la même qu’avec le hash classique, on évite juste qu’un mec récupère le pass si le hash est cassé.









charon.G a écrit :



a force de troller la dessus il faut pas raler sur le retour de baton…

Un peu facile ta remarque. enfin bref je vous laisse dans votre deni mais j’ai bien rigolé…







Joli épouventail on explique qu’un code libre est plus sur qu’un équivalent proprio grace à un audit de code plus large, et hop, on trouve une faille et on explique que : regardez les codes libres sont pas parfaits ! le proprio est mieux.



On a rien prouvé, on détourne ce qui a été dit, et vu que tout est forcément binaire, le proprio est forcément mieux vu que le libre est maintenant nul.



J’aimerai bien savoir si justement la faille n’a pas été découverte avec un audit de code … et pour le coup, oui, maintenant le code de OpenSSL est maintenant plus sûr qu’un code équivalent propriétaire … grâce à l’open source …



Il y a combien encore de failles de sécurités/backdoor non publiés dans les soft proprio qui sont potentiellement exploités ? <img data-src=" />







faut arrêter de jouer à l’idiot quand même ..









Impli a écrit :



J’ai du mal m’exprimer.



Quand je parle de modifier le hash, je parle de modifier légèrement le hash que l’on enverrai au serveur de façon à ce que si le hash est cassé, le pirate ne récupère pas le vrai mot de pass.

Après oui, le hash est toujours le même pour un pass donné. Mais là n’est pas là question.



Et si, le serveur reconnaîtra. Puisque, bien sûr, on ajoute le salt sur le hash modifié.

Au final la comparaison reste la même qu’avec le hash classique, on évite juste qu’un mec récupère le pass si le hash est cassé.





Ouai mais pour envoyer un hash modifié, il faut faire la modification côté client. Sauf que le code côté client est aussi connu du hacker, il faut donc un moyen qui permette, même en connaissant le code de modification, de ne pas retrouver l’original. Il faudrait donc… hasher le hash?

Ou sinon il faut une transformation réversible côté serveur en fonction d’un paramètre propre à la connexion utilisée l’instant t. Mais ça c’est le principe du chiffrement :P









Khalev a écrit :



Ouai mais pour envoyer un hash modifié, il faut faire la modification côté client. Sauf que le code côté client est aussi connu du hacker, il faut donc un moyen qui permette, même en connaissant le code de modification, de ne pas retrouver l’original. Il faudrait donc… hasher le hash?

Ou sinon il faut une transformation réversible côté serveur en fonction d’un paramètre propre à la connexion utilisée l’instant t. Mais ça c’est le principe du chiffrement :P







Dans tous les cas, la modif est faite côté client. Et est donc vulnérable. On peut juste limiter la casse en modifiant le hash pour éviter un traitement des données interceptées trop facilement.



Après je réagissais à une partie du paragraphe disant que la plupart du temps, les mots de pass sont transmis en clair au serveur. C’est de l’hérésie pure.



Sans même être expert en sécurité, on peut le hasher pour compliquer le travail des black hat (et limiter les dégats en cas de mot de pass utilisés sur plusieurs comptes). Ca ne rend pas le système invulnérable, on est d’accord.









Khalev a écrit :



Dans le doute, oui il vaut mieux. On ne sait pas si la faille n’était pas exploitée avant ça, si c’est le cas surement que des trucs ont pu fuiter de google & co.







Kidoki merci !









hadoken a écrit :



Si tu es technique et anglophone :http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html







Ouep j’ai déja regardé, c’est affolant qu’une telle “faille” puisse exister, je suis sur qu’elle a été massivement utilisé par quiconque y a pensé car c’est vraiment pas très complexe sur le principe et sur la pratique. Par contre l’exploitation des données obtenu grâce a la faille c’est un travail déjà qui s’annonce bien plus difficile.



Je disais juste que ça serait bien que PCInpact aborde le fond du problème pour les professionnels et autres passionnés ( possible réservé aux abonnées ? ) et globalement aille plus loin car même si la news est très complète, celle de lemonde est bien aussi et j’aimerai bien ne pas avoir a me baladé sur des sites anglophones ^^









atomusk a écrit :



Joli épouventail on explique qu’un code libre est plus sur qu’un équivalent proprio grace à un audit de code plus large, et hop, on trouve une faille et on explique que : regardez les codes libres sont pas parfaits ! le proprio est mieux.



On a rien prouvé, on détourne ce qui a été dit, et vu que tout est forcément binaire, le proprio est forcément mieux vu que le libre est maintenant nul.



J’aimerai bien savoir si justement la faille n’a pas été découverte avec un audit de code … et pour le coup, oui, maintenant le code de OpenSSL est maintenant plus sûr qu’un code équivalent propriétaire … grâce à l’open source …



Il y a combien encore de failles de sécurités/backdoor non publiés dans les soft proprio qui sont potentiellement exploités ? <img data-src=" />







faut arrêter de jouer à l’idiot quand même ..





Désolé je pense que j’ai mal été compris <img data-src=" /> , comme dit plus haut je commenterai plus sur cette news je vais dégager comme ça a été si gentiment proposé..

Pour le reste je t’ai envoyé un MP.









atomusk a écrit :



Joli épouventail on explique qu’un code libre est plus sur qu’un équivalent proprio grace à un audit de code plus large, et hop, on trouve une faille et on explique que : regardez les codes libres sont pas parfaits ! le proprio est mieux.



On a rien prouvé, on détourne ce qui a été dit, et vu que tout est forcément binaire, le proprio est forcément mieux vu que le libre est maintenant nul.



J’aimerai bien savoir si justement la faille n’a pas été découverte avec un audit de code … et pour le coup, oui, maintenant le code de OpenSSL est maintenant plus sûr qu’un code équivalent propriétaire … grâce à l’open source …



Il y a combien encore de failles de sécurités/backdoor non publiés dans les soft proprio qui sont potentiellement exploités ? <img data-src=" />







faut arrêter de jouer à l’idiot quand même ..





Pourrais tu citer le passage où il dit que le proprio est mieux ? Je ne le trouve pas … Oh wait !



Sa these c’est juste remettre en place les intégristes pour qui un code open source et libre écarte de facto les failles* et surtout prôner pour un OS en code managé (libre ou pas meme si il y’a de grande chance qu’il soit open source) permettant de parer a de nombreuse failles (bon pas dans ce cas) qu’un développeur humain peut faire …



* Et il y’en a beaucoup sur PCI … Ceux qui t’expliquent que la NSA ne peut pas avoir mis de backdoor dans linux parce que le code est audité a chaque commit et qu’il y a un processus long et strict avant d’intégrer la branche stable …

Or un faille non communiqué a la communauté est une forme de backdoor … De plus une faille de ce genre aurait pu etre mis en place volontairement …



Pareil sur la news gnuTLS etc …



Le seul problème c’est que c’est souvent les utilisateurs d’OS proprio qui doivent rappeler le simple fait que l’open source ne signifie seulement que réactivité et audit facile … Les libristes compétent ont également le droit de ramener dans le droit chemin les intégristes qui vomissent du FUD …









arno53 a écrit :



Pourrais tu citer le passage où il dit que le proprio est mieux ? Je ne le trouve pas … Oh wait !



Sa these c’est juste remettre en place les intégristes pour qui un code open source et libre écarte de facto les failles* et surtout prôner pour un OS en code managé (libre ou pas meme si il y’a de grande chance qu’il soit open source) permettant de parer a de nombreuse failles (bon pas dans ce cas) qu’un développeur humain peut faire …



* Et il y’en a beaucoup sur PCI … Ceux qui t’expliquent que la NSA ne peut pas avoir mis de backdoor dans linux parce que le code est audité a chaque commit et qu’il y a un processus long et strict avant d’intégrer la branche stable …

Or un faille non communiqué a la communauté est une forme de backdoor … De plus une faille de ce genre aurait pu etre mis en place volontairement …



Pareil sur la news gnuTLS etc …



Le seul problème c’est que c’est souvent les utilisateurs d’OS proprio qui doivent rappeler le simple fait que l’open source ne signifie seulement que réactivité et audit facile … Les libristes compétent ont également le droit de ramener dans le droit chemin les intégristes qui vomissent du FUD …





On doit vraiment pas lire les même commentaires.

J’ai jamais vu un libriste dire que du code en libre accès permettait de n’avoir aucune faille.

Et au contraire, je vois souvent des utilisateurs d’OS proprio qui affirment que le proprio c’est plus sécuritaire car on a pas accès au code source…









arno53 a écrit :



Sa these c’est juste remettre en place les intégristes





Peut-être, mais c’est souvent dit sous la forme «tous les libristes sont intégristes, tous les libristes crachent sur Microsoft». Après faut pas s’étonner que ça coince.



Sinon je pense qu’on est tous d’accord : dire que le libre est 100% sûr ça a toujours été du troll… Mettre les trolls et les libristes dans le même panier, ça fait mal, et forcément ça frite.









arno53 a écrit :



Pourrais tu citer le passage où il dit que le proprio est mieux ?







+1



Perso je n’avais plus le courage de répondre…









charon.G a écrit :



les buffer overflow c’est la très grande majorité des failles et ce n’est pas possible avec un langage managé…







Sur le web, les menaces les plus courantes viennent des failles de sites codés en PHP…. qui est pourtant un langage de type managé.



Les exploitations réussies de buffer overflow sur des programmes écrits en C/CC++ sont en pratique beaucoup plus rares.



La cause la plus courante de problèmes de sécurité n’est donc pas le langage de programmation utilisée, mais plutôt la compétence et le niveau des programmeurs.



Laisser penser que l’outil (en l’occurence le langage) pourrait remplacer la compétence, c’est prendre une mauvaise direction.



D’ailleurs rappelons que tous les langages permettent le “bound checking” , y compris C/C++. Il suffit d’accéder à la mémoire uniquement au travers de classes et de fonctions qui l’imposent . Ce qui est relativement simple à écrire.



Donc, a quoi bon utiliser un langage “managé”, juste pour avoir une fonctionnalité implémentable dans tous les langages ?



Ce qui m’amène à une tout autre conclusion : quantité de programmes sont anciens ou codés avec des paradigmes de programmations anciens qui datent du temps ou le web n’existait pas encore.



Parfois même ils utilisent encore des anciennes fonctions du type strcpy() dont les problèmes sont connus.



Ils devraient donc être réécrits avec de nouvelles règles.









240-185 a écrit :



La FSF



Et ils se défaussent en disant que le bug a été corrigé grâce à l’ouverture du code, tout en passant en silence le fait qu’il a quand même fallu deux ans pour le découvrir : http://www.fsf.org/news/free-software-foundation-statement-on-heartbleed-vulnerability







Sincèrement, je pense que tu n’as rien compris.



Commençons donc par casser une idée reçue largement véhiculée par le marketing : Non, l’ordinateur n’est pas un objet simple. C’est même l’objet le plus complexe jamais inventé par l’homme.



Dans tous les programmes, il y a des failles. Qu’ils soient libre ou propriétaire ne change rien au fait que les programmeurs en produisent.



La cause des failles dans les programmes, c’est principalement la très grande complexité des logiciels ET la nature humaine des programmeurs qui les écrivent.



La différence qu’offre le libre, c’est qu’il permet à tous de lire le code et de rechercher des failles. C’est un avantage réel et incontestable.



Mais cela signifie t’il pour autant l’absence de failles ? Bien sûr que non. Et jamais personne n’a prétendu cela.



Mais plus il y aura de gens qui liront les codes sources, plus vite les failles seront trouvées et éliminées.



C’est la ou se trouve le paradoxe.



Tout le monde sait que le logiciel libre et le seul moyen d’assurer l’indépendance du système d’exploitation des états parce qu’il rends plus facile la découverte de failles. Et donc complique leur introduction volontaire.



Mais pour que cela fonctionne de la manière la plus parfaite possible, il faudrait que les états consentent à y consacrer des ressources suffisantes pour vérifier le code et contribuer à sa sécurité.



Ce qui n’est malheureusement pas encore le cas.



Nous voyons très bien d’ou viens le problème en observant le mauvais exemple de la France qui prends un monstrueux retard à se mettre aux logiciels libres.










Adelio a écrit :



Donc si j’ai bien compris, si on s’est connecté sur un site vulnérable entre la découverte de la faille et aujourd’hui, il est indispensable de changer le mot de passe. Mais si on ne s’est pas connecté, les risques de piratage sont moindres mais ça n’évite pas le risque zéro.









Techniquement comme la faille est là depuis deux ans, quelqu’un peut s’en servir sur les machines INpactées depuis ce moment…









sr17 a écrit :



Sur le web, les menaces les plus courantes viennent des failles de sites codés en PHP…. qui est pourtant un langage de type managé.





Personne n’a dit que toutes les failles allaient disparaitre <img data-src=" />

Se débarrasser des failles liées à la mémoire est déjà un grand pas.







sr17 a écrit :



Les exploitations réussies de buffer overflow sur des programmes écrits en C/CC++ sont en pratique beaucoup plus rares.





Certes, mais elles sont aussi bien plus critiques.









sr17 a écrit :



La cause la plus courante de problèmes de sécurité n’est donc pas le langage de programmation utilisée, mais plutôt la compétence et le niveau des programmeurs.





Oui, mais à compétences égales, un code managé contiendra moins d’erreurs que du C.







sr17 a écrit :



D’ailleurs rappelons que tous les langages permettent le “bound checking” , y compris C/C++. Il suffit d’accéder à la mémoire uniquement au travers de classes et de fonctions qui l’imposent . Ce qui est relativement simple à écrire.



Donc, a quoi bon utiliser un langage “managé”, juste pour avoir une fonctionnalité implémentable dans tous les langages ?





Pourquoi implementer quelque chose que des gens infiniments plus compétents que nous ont déjà fait ?







sr17 a écrit :



Ce qui m’amène à une tout autre conclusion : quantité de programmes sont anciens ou codés avec des paradigmes de programmations anciens qui datent du temps ou le web n’existait pas encore.



Parfois même ils utilisent encore des anciennes fonctions du type strcpy() dont les problèmes sont connus.



Ils devraient donc être réécrits avec de nouvelles règles.





C’est surtout qu’il faut adopter un modèle hybride: du C/C++ où la performance est critique, du C#/Java/Haskell/whatever pour tout le reste.









hadoken a écrit :



+1



Perso je n’avais plus le courage de répondre…





Honnêtement, c’était quoi le but de ton message ? Troller les trolls ?



Imagine la situation inverse : si je vais sur la news du bug de màj pour Windows 8.1 et que j’écris :



Ah, je croyais que contrairement aux logiciels libres, les logiciels proprio étaient développés par des professionnels, et donc que ce genre de bug ne pouvait pas arriver



Tu crois qu’il se passera quoi ? Perso je pense que mon message sera supprimé pour troll, et s’il ne l’est pas, un tas de gens me tomberont dessus. Même si, après coup, j’explique que je ne visais que les intégristes pro-logiciels propriétaires, le mal sera fait. Un tel message est trop ambigu, ça fait trop d’amalgame, on ne sait pas s’il faut le prendre au 1er ou au 15e degré… Bref c’est de la provoc, il ne faut pas s’étonner que la conversation parte en vrille après ça.









dam1605 a écrit :



Techniquement comme la faille est là depuis deux ans, quelqu’un peut s’en servir sur les machines INpactées depuis ce moment…







Les professionnels de la sécurité te diront que sur tous les OS existants, il existe des failles dormantes et exploitables que personne n’a encore découvert.



Et il se peut aussi que certaines soient connues d’un petit nombre de personnes avec toutes les conséquences que cela pourrait supposer.



Etant donné l’importance de la sécurité informatique (parce que nous confions maintenant toute notre vie aux ordinateurs), cela pourrait bien devenir LE problème du siècle.



La question qu’il faut se poser c’est : qu’est ce qu’on peut y faire.



Parce que oui, nous pouvons y faire quelque chose. Mais il faudra y consacrer de très lourds moyens.



Pour garantir que la sécurité sera indépendante d’un état, seul les logiciels libres seront adéquats.



Mais il faudra aussi que les états prennent aussi conscience que ce n’est pas suffisant et qu’il sera nécessaire d’y consacrer des moyens.












sr17 a écrit :



Les professionnels de la sécurité te diront que sur tous les OS existants, il existe des failles dormantes et exploitables que personne n’a encore découvert.



Et il se peut aussi que certaines soient connues d’un petit nombre de personnes avec toutes les conséquences que cela pourrait supposer.



Etant donné l’importance de la sécurité informatique (parce que nous confions maintenant toute notre vie aux ordinateurs), cela pourrait bien devenir LE problème du siècle.



La question qu’il faut se poser c’est : qu’est ce qu’on peut y faire.



Parce que oui, nous pouvons y faire quelque chose. Mais il faudra y consacrer de très lourds moyens.



Pour garantir que la sécurité sera indépendante d’un état, seul les logiciels libres seront adéquats.



Mais il faudra aussi que les états prennent aussi conscience que ce n’est pas suffisant et qu’il sera nécessaire d’y consacrer des moyens.







Fallait pas le prendre mal, je soulignais juste que les système était vulnérables bien avant que la faille soit rendue publique.



Sinon je suis plutôt d’accord avec toi <img data-src=" />









arno53 a écrit :



Pourrais tu citer le passage où il dit que le proprio est mieux ? Je ne le trouve pas … Oh wait !







Je m’en fout. Ce genre d’insinuation débiles comme quoi c’est pas parce qu’un code est ouvert qu’il est plus sûr est débile. LE CODE EST MAINTENANT PLUS SUR BORDEL ET C’EST PARCE QU’IL EST OUVERT QU’ON A CONFIANCE EN LUI.



C’est EVIDENT qu’un code ouvert est plus sûr, et faut être un demeuré pour penser que un code libre n’aura pas de failles de sécurités grave. Putain on est sur PCI NextInpact, c’est pas twitter, Facebook ou les commentaires de Yahoo News. Ici il y a des devs, des personnes qui savent développer, et qui savent ce que ça veux dire de faire un code parfait. (pour info, c’est impossible)



Des failles il y en a, il y en aura, que le code soit libre ou pas. Maintenant, oui, j’ai plus confiance en un code open source. Est-ce que je vais pleurer à la mort parce que ma confiance a été trahie ? Non et je la sait PARCE QUE je suis un dev.







arno53 a écrit :



Sa these c’est juste remettre en place les intégristes







Hop j’arrete de lire, donc sa thése c’est d’être plus con que les cons ? OK c’est cool ! Sympa, on avait une news constructive et on part en NANANANAANA ! VOUS VOYEZ QUE LE CODE IL EST PAS PARFAIT !



Ca sert à rien, c’est un comportement de maternelle et c’est con.



Voilà c’était mon coup de geule du soir, non, Charon, je répondrai pas à ton PM, je le lirai même pas, ce débat me débecte d’un coté comme de l’autre.

Je trouve les 2 coté aussi con, autant les fanboys qui refusent tout ce qui n’est pas libre que les mecs qui balancent des betises sur les news comme ça.



Heureusement que je suis arrivé à la bourre sinon j’aurai modéré les commentaires et bloqué sur la news.



ps: oui je suis énervé, mais quand je viens voir des info intéressantes dans les commentaires et que je vois un mec comme Charon dire un truc pareil, je peux pas être calme non plus.









jrbleboss a écrit :



Personne n’a dit que toutes les failles allaient disparaitre <img data-src=" />

Se débarrasser des failles liées à la mémoire est déjà un grand pas.







Je n’ai pas dit le contraire, mais simplement fait remarquer que ce n’était pas une question de langage.





Certes, mais elles sont aussi bien plus critiques.





Pas nécessairement.



Une faille dans un programme écrit en PHP peut parfaitement permettre à un pirate d’accéder à toutes les données critiques d’un site.





Oui, mais à compétences égales, un code managé contiendra moins d’erreurs que du C.





Non, ça c’est une idée reçue.



En C++, obtenir la même sécurité qu’un Java ou en C# est simple comme bonjour : il suffit de passer par des classes qui manipulent la mémoire.



Le problème de la compétence, c’est plutôt la tentation de certaines entreprises d’employer des gens qui n’ont pas le minimum requis en matière de sécurité informatique.





Pourquoi implementer quelque chose que des gens infiniments plus compétents que nous ont déjà fait ?





D’abord parce que les langages managés ne sont pas la solution universelle. Ils posent d’autres types de problèmes.



Ensuite parce qu’un “bound checking” est probablement la chose la plus triviale qu’on puisse imaginer en programmation.



Si un programmeur (même débutant) ne maîtrise pas cela, c’est qu’il doit changer de métier.



Il y a un moment ou il faudrait que la profession cesse d’utiliser des gens qui n’ont pas le strict minimum en terme de bagage technique en croyant qu’il existe un langage miracle qui va tout régler.





C’est surtout qu’il faut adopter un modèle hybride: du C/C++ où la performance est critique, du C#/Java/Haskell/whatever pour tout le reste.





C’est une vision des choses. Mais elle se heurte à quelques écueils : Un programme peut avoir en même temps besoin de performances d’un côté et de sécurité de l’autre. D’ou l’intérêt d’un langage capable de mixer les deux logique.



D’ou mon commentaire pour faire remarquer que contrairement aux idées reçues, un langage comme C++ est parfaitement capable de faire ce que font les langages managés. L’inverse n’est en revanche pas vrai.









atomusk a écrit :



Pas content, et il y a de quoi







Simplement merci pour ton coup de gueule contre les trolls récurrents.



Ma position, la voici :







Commentaire_supprime a écrit :



TOUT est vulnérable RIEN n’est bullet-proof, peu importe la licence.



Le libre, c’est faire un pari sur la réactivité de la communauté en cas de pépin.



Le proprio, c’est faire un pari sur le professionnalisme du détenteur des droits sur le code en cas de pépin.



Après, à vous de voir. Le reste n’est que troll de bas étage.







Et je rajouterait que c’est franchement dommage que l’on s’embourbe dans des débats que je considère (peut-être à tort) comme obsolètes, avec lâcher de trolls velus des deux cotés.



Sur ce, bonne nuit.









sr17 a écrit :



La différence qu’offre le libre, c’est qu’il permet à tous de lire le code et de rechercher des failles. C’est un avantage réel et incontestable.



Mais cela signifie t’il pour autant l’absence de failles ? Bien sûr que non. Et jamais personne n’a prétendu cela.



Mais plus il y aura de gens qui liront les codes sources, plus vite les failles seront trouvées et éliminées.







Je ne suis pas d’accord avec ça.



L’expérience et l’histoire montrent que peu importe que le source soit disponible ou non, on trouve toujours plus de failles dans les logiciels les plus utilisés.



Exemple tout bête, IE6 ou Flash, tous les deux fermés, et pourtant plein de failles trouvées par des gens uniquement en utilisant le disassembly. Pourquoi? Simplement parce que ça se vend très cher, ou ça rapporte beaucoup d’argent à l’exploitation.



Il suffit de voir les bug bounty programs : le nombre de failles rapportées est proportionnel à la popularité des softs, en gros. L’aspect code source dispo ou non ne semble pas influer.



Personnellement, ayant écrit des outils d’analyse statique et dynamique de code, j’ai trouvé quelques failles, mais uniquement dans des softs open-source. L’analyse sur du code compilé est plus complexe à mettre en oeuvre (mais c’est dans les tuyaux en ce qui me concerne).



Aujourd’hui, il me reste 3 failles critiques à rapporter : une dans le kernel linux, une dans firefox, et une dans java (découverte à partir de la JVM compilée). Donc 2 open source, 1 closed source (mais open depuis), mais tous très utilisés : c’est ça le point commun.



Pour un compte yahoo sur lequel je ne me suis pas connecté depuis un moment, il ne faut donc pas que j’y aille pour le moment, ou faut il que j’aille changer le mot de passe justement ?



J’ai un peu de mal là ^^



Merci :)








Commentaire_supprime a écrit :



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />



TOUT est vulnérable RIEN n’est bullet-proof, peu importe la licence.



Le libre, c’est faire un pari sur la réactivité de la communauté en cas de pépin.



Le proprio, c’est faire un pari sur le professionnalisme du détenteur des droits sur le code en cas de pépin.



Après, à vous de voir. Le reste n’est que troll de bas étage.







La question n’est au contraire pas du tout un troll. C’est bien un problème sérieux dont les enjeux sont majeurs.



Quand un unique module de code finit par servir de porte de sécurité à de nombreux ordinateurs et services dans le monde, il est évident que les conséquences d’un problème peuvent être absolument critiques, aussi bien pour des individus que des entreprises ou même des états.



La vraie question qui se pose est la suivante : est ce que la responsabilité de la sécurité d’un tel module ne devient pas un enjeu beaucoup trop lourd pour reposer sur un faible nombre d’individus, une seule entreprise ou un seul état ?



A partir du moment ou l’on pose la conclusion logique que de tels enjeux ne peuvent être solutionnés que par un nombre d’équipes importantes et multi nationales pour garantir les intérêts de tous, on pose également la conclusion qu’il serait difficile de travailler autrement que dans une logique de logiciel libre.









dam1605 a écrit :



Fallait pas le prendre mal, je soulignais juste que les système était vulnérables bien avant que la faille soit rendue publique.



Sinon je suis plutôt d’accord avec toi <img data-src=" />







Pas de souci, c’était surtout l’occasion d’expliquer le pourquoi du comment.









herbeapipe a écrit :



Pour un compte yahoo sur lequel je ne me suis pas connecté depuis un moment, il ne faut donc pas que j’y aille pour le moment, ou faut il que j’aille changer le mot de passe justement ?



J’ai un peu de mal là ^^



Merci :)







Tant que tu n’as pas l’info disant que le problème est solutionné chez eux, il est prudent de ne pas t’y connecter.



Une fois le problème solutionné, tu pourra t’y connecter et changer ton mot de passe afin de parer au cas ou la faille aurait pu être exploitée par le passé.









sr17 a écrit :



Tant que tu n’as pas l’info disant que le problème est solutionné chez eux, il est prudent de ne pas t’y connecter.



Une fois le problème solutionné, tu pourra t’y connecter et changer ton mot de passe afin de parer au cas ou la faille aurait pu être exploitée par le passé.







Merci pour l’info ;)









Freud a écrit :



Je ne suis pas d’accord avec ça.



L’expérience et l’histoire montrent que peu importe que le source soit disponible ou non, on trouve toujours plus de failles dans les logiciels les plus utilisés.



Exemple tout bête, IE6 ou Flash, tous les deux fermés, et pourtant plein de failles trouvées par des gens uniquement en utilisant le disassembly. Pourquoi? Simplement parce que ça se vend très cher, ou ça rapporte beaucoup d’argent à l’exploitation.



Il suffit de voir les bug bounty programs : le nombre de failles rapportées est proportionnel à la popularité des softs, en gros. L’aspect code source dispo ou non ne semble pas influer.



Personnellement, ayant écrit des outils d’analyse statique et dynamique de code, j’ai trouvé quelques failles, mais uniquement dans des softs open-source. L’analyse sur du code compilé est plus complexe à mettre en oeuvre (mais c’est dans les tuyaux en ce qui me concerne).



Aujourd’hui, il me reste 3 failles critiques à rapporter : une dans le kernel linux, une dans firefox, et une dans java (découverte à partir de la JVM compilée). Donc 2 open source, 1 closed source (mais open depuis), mais tous très utilisés : c’est ça le point commun.







Tu dit toi même qu’il est plus difficile de travailler avec un logiciel dont le code source n’est pas disponible.



Et si je conviens que les outils d’analyse complètent fort utilement l’analyse humaine, il ne faut pas oublier qu’ils ne peuvent pas pour autant la remplacer.



Enfin, pour un programmeur d’outil d’analyse, l’enjeu est de repérer toutes les failles qu’il lui sera possible de détecter. Mais pour un programmeur de logiciels et ses utilisateurs, l’enjeu est de les trouver toutes.



Pour un humain, quel est le plus rapide à lire ? La sortie d’un code source ou celle d’un désassembleur ? Tu conviendra que la réponse est évidente.



Et le fait est que Java est beaucoup plus facile à décompiler que C++, c’est donc un mauvais exemple pour parler de la difficulté de trouver des failles dans le code “closed source”.



Le fait qu’un logiciel très utilisé soit également plus étudié sur le plan de la sécurité me parait aussi assez logique.



Donc je pense que globalement nous ne sommes pas en désaccord.









sr17 a écrit :



Et le fait est que Java est beaucoup plus facile à décompiler que C++, c’est donc un mauvais exemple pour parler de la difficulté de trouver des failles dans le code “closed source”.







Je parlais de la JVM hotspot, donc du C++ :)









sr17 a écrit :



Une faille dans un programme écrit en PHP peut parfaitement permettre à un pirate d’accéder à toutes les données critiques d’un site.





Ça reste quand même à des années lumières d’une faille qui permet de l’exécution de code.







sr17 a écrit :



En C++, obtenir la même sécurité qu’un Java ou en C# est simple comme bonjour : il suffit de passer par des classes qui manipulent la mémoire.





<img data-src=" />







sr17 a écrit :



Le problème de la compétence, c’est plutôt la tentation de certaines entreprises d’employer des gens qui n’ont pas le minimum requis en matière de sécurité informatique.





Je ne doute pas que tu sois un programmeur de génie, mais mon propos est général. J’ai plaisir à utiliser du C/C++ tout autant que du C#/Python/Haskell, mais il ne faut pas se mentir, tout le monde fait des erreurs et certains langages en permettent beaucoup plus que d’autres, c’est indéniable.







sr17 a écrit :



D’abord parce que les langages managés ne sont pas la solution universelle. Ils posent d’autres types de problèmes.





Je suis absolument d’accord. Je pense néanmoins, qu’il y a énormément de code qui n’a aucune valeur à être en C et pourrait être dans un langage plus sûr. Sûr dans le sens où une manipulation mémoire directe en C n’est souvent pas justifiable.







sr17 a écrit :



Ensuite parce qu’un “bound checking” est probablement la chose la plus triviale qu’on puisse imaginer en programmation.



Si un programmeur (même débutant) ne maîtrise pas cela, c’est qu’il doit changer de métier.





Outre le niveau de compétence, il me semble qu’aujourd’hui, on n’utilise pas assez les outils qui sont à notre disposition. Un langage comme Ada ou Haskell ont des compilateurs qui vérifient des contraintes beaucoup plus poussées qu’en C/C++/C#/Java. Pourquoi ce priver de cela ? Parce qu’on est trop des roxxors du code et on n’en a pas besoin ? <img data-src=" />







sr17 a écrit :



Il y a un moment ou il faudrait que la profession cesse d’utiliser des gens qui n’ont pas le strict minimum en terme de bagage technique en croyant qu’il existe un langage miracle qui va tout régler.





J’ai jamais dit que cela allait tout régler. C’est juste qu’il y a beaucoup de cas où utiliser du C ne se justifie plus aujourd’hui.







sr17 a écrit :



C’est une vision des choses. Mais elle se heurte à quelques écueils : Un programme peut avoir en même temps besoin de performances d’un côté et de sécurité de l’autre. D’ou l’intérêt d’un langage capable de mixer les deux logique.





On a jamais le beurre et l’argent du beurre. Il ne faut pas rêver. Ce n’est pas pour rien que les trains, avions, fusées, missiles, etc… ne sont pas codés en C, mais principalement en Ada. Et dans pas mal de cas, je sacrifierais volontiers 10% de performances et la garantie de ne pas avoir d’erreurs aussi bêtes.







sr17 a écrit :



D’ou mon commentaire pour faire remarquer que contrairement aux idées reçues, un langage comme C++ est parfaitement capable de faire ce que font les langages managés. L’inverse n’est en revanche pas vrai.





Oui, tout autant qu’en assembleur tu peux faire la même chose qu’en C++.

La différence c’est 100x fois plus de chance d’avoir des bugs, un temps de développement bien plus long, etc…









Jarodd a écrit :



La version bugguée date de 2012, et on coupe les sites depuis hier ? <img data-src=" />



On sait de qui est sortie l’info de cette faille ? Qui l’a dévoilé, et quand exactement ? Ca a été corrigé avant ou après la divulgation ?







Ca a été dévoilé par un gars de chez Google.







hadoken a écrit :



Heureusement que l’Open Source est a l’abri des failles de sécurité grâce aux nombreux contributeurs / relecteurs !



<img data-src=" />







Il est probable/possible que certains black hat aient trouvé la faille avant et l’aient exploitée pour eux. Mais c’est bien sûr encore pire pour le logiciel propriétaire. En effet, les failles ainsi découvertes par les black hat peuvent persister encore plus longtemps avant que quelqu’un s’en aperçoive vu que le code n’est pas public.



Et il est clair qu’avec l’ampleur que prend de plus en plus l’Open Source, et c’est irrémédiable, il a une telle force de frappe que plus aucune entreprise ne peut s’aligner de façon économiquement viable, de telles “découvertes” sont amenées à se multiplier à l’avenir.



La rançon du succès en quelque sorte !.. Si OpenSSL n’était utilisé que par 2 sites dans le monde, ça ne ferait aucun bruit.









jrbleboss a écrit :



Je ne doute pas que tu sois un programmeur de génie, mais mon propos est général. J’ai plaisir à utiliser du C/C++ tout autant que du C#/Python/Haskell, mais il ne faut pas se mentir, tout le monde fait des erreurs et certains langages en permettent beaucoup plus que d’autres, c’est indéniable.







Il y a cependant des outils, pour le C, qui vont beaucoup plus loin que ce que ne fait le compilateur. C’est le cas de l’ancien splint par exemple qui est capable de suivre dans tout un programme depuis l’allocation mémoire jusqu’à sa désallocation et regarder tous ceux qui la manipulent au milieu.



Ca te trouve aussi plein d’autres bugs “potentiels”, comme par exemple comparer directement 2 booleens (unsafe puisque la norme C définit 0/autre chose).



Ca corrige bien des bugs…. mais c’est vrai que c’est ch… à utiliser et du coup peu de gens le font.



LLVM/Clang est en train de “moderniser” splint et de l’améliorer. Le travail n’est pas fini mais ça s’annonce prometteur.





Quant à l’affirmation qu’on peut faire la même chose en C++ qu’en assembleur… laissez moi rire. Certes on peut, dans la théorie. Mais avez vous essayé de programmer un Lempel et Ziv en C/C++. C’est un algo qui travaille sur des mots de taille variable : 7bits, 8bits, 9bits, etc… Alors l’écrire en C/C++ c’est juste à peu près 1000 fois moins rapide qu’en assembleur où on peut faire des trucs du genre : rotation de bits d’un registre vers un autre (en x86).



Il y a donc la “théorie”, C est effectivement un langage “Turing complete”… mais XSLT aussi. Je ne vois pas utiliser l’un à la place de l’autre dans 100% des cas, même si c’est théoriquement possible.



En réalité, chaque langage a son champ d’application où il excelle, et il faut utiliser le “bon outil” pour ce qu’on a à faire.









atomusk a écrit :



C’est EVIDENT qu’un code ouvert est plus sûr, et faut être un demeuré pour penser que un code libre n’aura pas de failles de sécurités grave. Putain on est sur PCI NextInpact, c’est pas twitter, Facebook ou les commentaires de Yahoo News. Ici il y a des devs, des personnes qui savent développer, et qui savent ce que ça veux dire de faire un code parfait. (pour info, c’est impossible)



Des failles il y en a, il y en aura, que le code soit libre ou pas. Maintenant, oui, j’ai plus confiance en un code open source. Est-ce que je vais pleurer à la mort parce que ma confiance a été trahie ? Non et je la sait PARCE QUE je suis un dev.







Non, c’est TON évidence, elle n’est pas universelle.

Les outils d’analyse de code existent mais sont utilisées par tous les éditeurs sérieux, sur ce point, tout le monde est égal.

Par contre, affirmer que le code libre est plus sécurisé car tout le monde peut le lire, me fait hérisser les poils.

Jamais un hacker ne regarde le code pour trouver une faille.

Une faille se trouve en attaquant et en analysant les réponses de ces attaques.









atomusk a écrit :



Hop j’arrete de lire, donc sa thése c’est d’être plus con que les cons ? OK c’est cool ! Sympa, on avait une news constructive et on part en NANANANAANA ! VOUS VOYEZ QUE LE CODE IL EST PAS PARFAIT !



Ca sert à rien, c’est un comportement de maternelle et c’est con.



Voilà c’était mon coup de geule du soir, non, Charon, je répondrai pas à ton PM, je le lirai même pas, ce débat me débecte d’un coté comme de l’autre.

Je trouve les 2 coté aussi con, autant les fanboys qui refusent tout ce qui n’est pas libre que les mecs qui balancent des betises sur les news comme ça.



Heureusement que je suis arrivé à la bourre sinon j’aurai modéré les commentaires et bloqué sur la news.



ps: oui je suis énervé, mais quand je viens voir des info intéressantes dans les commentaires et que je vois un mec comme Charon dire un truc pareil, je peux pas être calme non plus.







Là, c’est sur la forme mais si tu ne sais pas garder ton calme, arrête la modération.

Avoir un avis, c’est une chose, t’énerver parce que les intervenants ne sont pas d’accord avec TES “évidences” en est une autre.










sepas a écrit :



Non, c’est TON évidence, elle n’est pas universelle.

Les outils d’analyse de code existent mais sont utilisées par tous les éditeurs sérieux, sur ce point, tout le monde est égal.

Par contre, affirmer que le code libre est plus sécurisé car tout le monde peut le lire, me fait hérisser les poils.





Ce n’est pas le propos.



Oui, n’importe quel logiciel a des failles (libre ou pas). Oui, la découverte de failles n’est pas forcément facilitée parce que le code est ouvert (les failles sont souvent découvertes sur des versions compilées des programmes).



Par contre, l’argument c’est de dire : un code source ouvert permet à différentes entités de corriger des failles plus facilement, plus rapidement, et permet à tous ceux qui le souhaitent de vérifier le correctif. Ça c’est une évidence, et c’est dans ce sens-là que atomsk disait qu’un code ouvert est plus sécurisé.



Et puis réfléchissez : si Microsoft se met à faire de l’Open Source, c’est bien parce qu’ils reconnaissent qu’il y a des avantages à ce travail collaboratif. Ça permet un développement plus rapide, ça facilite l’adoption par les développeurs, donc le succès d’un outil…



Vous ne pouvez pas dire d’un côté, «le libre n’apporte rien, n’est pas plus sûr», et de l’autre, «je ne suis pas anti-libre puisque Microsoft fait de l’Open Source, et j’aime bien Microsoft»…









Konrad a écrit :



Ce n’est pas le propos.



Oui, n’importe quel logiciel a des failles (libre ou pas). Oui, la découverte de failles n’est pas forcément facilitée parce que le code est ouvert (les failles sont souvent découvertes sur des versions compilées des programmes).



Par contre, l’argument c’est de dire : un code source ouvert permet à différentes entités de corriger des failles plus facilement, plus rapidement, et permet à tous ceux qui le souhaitent de vérifier le correctif. Ça c’est une évidence, et c’est dans ce sens-là que atomsk disait qu’un code ouvert est plus sécurisé.



Et puis réfléchissez : si Microsoft se met à faire de l’Open Source, c’est bien parce qu’ils reconnaissent qu’il y a des avantages à ce travail collaboratif. Ça permet un développement plus rapide, ça facilite l’adoption par les développeurs, donc le succès d’un outil…



Vous ne pouvez pas dire d’un côté, «le libre n’apporte rien, n’est pas plus sûr», et de l’autre, «je ne suis pas anti-libre puisque Microsoft fait de l’Open Source, et j’aime bien Microsoft»…







Je ne dis pas que le libre n’apporte rien, je n’ai fait qu’une intervention sur ce post, je viens de la relire, et je n’ai pas dit ça.



Sinon, pour ta réponse : Permettre à plusieurs entité de corriger…Oui sauf que dans ce cas précis, chaque entité déploie son propre correctif…donc je vois pas trop l’avantage. Un éditeur propriétaire aurait fait la même chose.

Et vérifier le code du correctif…Honnêtement, tu crois qu’il y a beaucoup de boites qui vérifient le code d’un correctif? Déjà qu’il y en a très peu qui passent les patchs….



Je ne dénigre pas le libre, je pense juste que les solutions sont équivalentes avec des avantages/inconvénients pour chacune d’entre elles.



Quand les entreprises font un choix libre/propriétaire c’est rarement pour la raison libre/propriétaire mais parceque le soft répond à leur besoin fonctionnel.

Je n’ai jamais vu un DSI me dire qu’il voulait du libre pour lire le code d’un OS, d’une application ou d’un patch

On doit pas voir les même DSI









sepas a écrit :



Je ne dis pas que le libre n’apporte rien, je n’ai fait qu’une intervention sur ce post, je viens de la relire, et je n’ai pas dit ça.



Sinon, pour ta réponse : Permettre à plusieurs entité de corriger…Oui sauf que dans ce cas précis, chaque entité déploie son propre correctif…donc je vois pas trop l’avantage. Un éditeur propriétaire aurait fait la même chose.

Et vérifier le code du correctif…Honnêtement, tu crois qu’il y a beaucoup de boites qui vérifient le code d’un correctif? Déjà qu’il y en a très peu qui passent les patchs….



Je ne dénigre pas le libre, je pense juste que les solutions sont équivalentes avec des avantages/inconvénients pour chacune d’entre elles.



Quand les entreprises font un choix libre/propriétaire c’est rarement pour la raison libre/propriétaire mais parceque le soft répond à leur besoin fonctionnel.

Je n’ai jamais vu un DSI me dire qu’il voulait du libre pour lire le code d’un OS, d’une application ou d’un patch

On doit pas voir les même DSI





Attention aux termes. MS peut très bien ouvrir son code en restant propriétaire.



Sinon, j’ai vu des associations où le libre est un choix délibéré pour éviter les dépenses en licences.



Il y a également un service sécurité là où je bosse actuellement qui vérifie et teste les patchs OS et software sous toutes les coutures.



Après, oui, c’est aussi un choix fonctionnel.

Un logiciel open-source sera également beaucoup plus maintenable et adaptable sans avoir à recourir aux prestations éditeurs hors de prix. Et je dis ça sans mauvaise foi, je suis consultant pour un éditeur de logiciel proprio.



A contrario, un logiciel qui convient parfaitement aux besoins, et sans besoin évolutifs particuliers peut très bien être propriétaire. Cela vaut surtout pour les particuliers.

Mais dans ce cas, on ne peut que faire confiance à l’éditeur pour assurer le support.









sepas a écrit :



Non, c’est TON évidence, elle n’est pas universelle.

Les outils d’analyse de code existent mais sont utilisées par tous les éditeurs sérieux, sur ce point, tout le monde est égal.

Par contre, affirmer que le code libre est plus sécurisé car tout le monde peut le lire, me fait hérisser les poils.

Jamais un hacker ne regarde le code pour trouver une faille.

Une faille se trouve en attaquant et en analysant les réponses de ces attaques.





Je voulais pas répondre mais il y a pas mal de gens qui me font tenir des propos que je n’ai pas tenu et que je ne pense pas du tout..

Perso je regrette d’avoir quoter hadoken je visais qu’“une tranche d’intégriste en particulier.

ce que vient de dire sepas , je l’ai envoyé par MP à atomusk hier mais bon vu qu’il refuse de nouer le dialogue c’est son droit



.



Konrad a écrit :



Ce n’est pas le propos.



Oui, n’importe quel logiciel a des failles (libre ou pas). Oui, la découverte de failles n’est pas forcément facilitée parce que le code est ouvert (les failles sont souvent découvertes sur des versions compilées des programmes).



Par contre, l’argument c’est de dire : un code source ouvert permet à différentes entités de corriger des failles plus facilement, plus rapidement, et permet à tous ceux qui le souhaitent de vérifier le correctif. Ça c’est une évidence, et c’est dans ce sens-là que atomsk disait qu’un code ouvert est plus sécurisé.



Et puis réfléchissez : si Microsoft se met à faire de l’Open Source, c’est bien parce qu’ils reconnaissent qu’il y a des avantages à ce travail collaboratif. Ça permet un développement plus rapide, ça facilite l’adoption par les développeurs, donc le succès d’un outil…



Vous ne pouvez pas dire d’un côté, «le libre n’apporte rien, n’est pas plus sûr», et de l’autre, «je ne suis pas anti-libre puisque Microsoft fait de l’Open Source, et j’aime bien Microsoft»…





le libre apporte beaucoup de choses mais désolé sur la sécurité c’est loin de régler le problème. Il existe des dizaines de milliers de failles latentes dans le code qui n’ont pas encore été découvertes.

En effet tu vas peut être trouver quelques failles en plus en lisant le source code mais dans les faits tu ne peux pas faire confiance à un humain. Il fera toujours des bugs et il ne les trouvera pas forcément.





Les solutions efficaces pour lutter contre ce genre de faille sont les sandbox en limitant la portée de l’attaque ou le code managé par exemple mais désolé tu ne peux pas faire confiance à un humain…









ActionFighter a écrit :



Attention aux termes. MS peut très bien ouvrir son code en restant propriétaire.



Sinon, j’ai vu des associations où le libre est un choix délibéré pour éviter les dépenses en licences.



Il y a également un service sécurité là où je bosse actuellement qui vérifie et teste les patchs OS et software sous toutes les coutures.



Après, oui, c’est aussi un choix fonctionnel.

Un logiciel open-source sera également beaucoup plus maintenable et adaptable sans avoir à recourir aux prestations éditeurs hors de prix. Et je dis ça sans mauvaise foi, je suis consultant pour un éditeur de logiciel proprio.



A contrario, un logiciel qui convient parfaitement aux besoins, et sans besoin évolutifs particuliers peut très bien être propriétaire. Cela vaut surtout pour les particuliers.

Mais dans ce cas, on ne peut que faire confiance à l’éditeur pour assurer le support.







On est d’accord <img data-src=" />

Par contre, je vois très peu de boite qui prennent du libre dans l’optique de faire évoluer un produit. La plupart veulent réduire au maximum le développement.









charon.G a écrit :



(…)mais dans les faits tu ne peux pas faire confiance à un humain. Il fera toujours des bugs et il ne les trouvera pas forcément.



Les solutions efficaces pour lutter contre ce genre de faille sont les sandbox en limitant la portée de l’attaque ou le code managé par exemple mais désolé tu ne peux pas faire confiance à un humain…







J’entends bien et je ne suis pas en total désaccord…

Comme tu le dis, “on ne peut pas faire confiance à l’humain”, c’est vrai mais c’est toujours l’humain qui produit : les sandbox, les machines virtuelles…



Pourquoi accorder plus de confiance à l’humain qui développe la machine virtuelle Java par exemple ?



Il y a de toute façon un moment où il n’y a pas d’autre choix que de faire confiance à l’humain, non ? (humain ici peut être une entité privée, une communauté de libriste… peu importe).









malock a écrit :



J’entends bien et je ne suis pas en total désaccord…

Comme tu le dis, “on ne peut pas faire confiance à l’humain”, c’est vrai mais c’est toujours l’humain qui produit : les sandbox, les machines virtuelles…



Pourquoi accorder plus de confiance à l’humain qui développe la machine virtuelle Java par exemple ?



Il y a de toute façon un moment où il n’y a pas d’autre choix que de faire confiance à l’humain, non ? (humain ici peut être une entité privée, une communauté de libriste… peu importe).







D’où l’importance d’avoir une base fiable.



Ce que dit Charon, c’est que si l’OS est conçu pour être safe (la sandbox en est un bon exemple), moins il y a de risque.

La sandbox peut-être buggué mais elle évoluera, les bugs seront corrigés comme pour le reste.

Mais le gros avantages, et que tout ce qui sera au dessus sera safe.



Sans Sandbox, tu multiplies les risques.



Personne n’affirme qu’il est possible d’avoir 0 bugs mais il est possible de les diminuer avec un OS bien pensé.









malock a écrit :



J’entends bien et je ne suis pas en total désaccord…

Comme tu le dis, “on ne peut pas faire confiance à l’humain”, c’est vrai mais c’est toujours l’humain qui produit : les sandbox, les machines virtuelles…



Pourquoi accorder plus de confiance à l’humain qui développe la machine virtuelle Java par exemple ?



Il y a de toute façon un moment où il n’y a pas d’autre choix que de faire confiance à l’humain, non ? (humain ici peut être une entité privée, une communauté de libriste… peu importe).





C”est déjà bien meilleur en terme de sécurité. Pour sortir d’une sandbox il faut une faille d’escalade de privilege il y en a rarement dans les faits. Dans le futur tu peux aussi te passer de runtime, écrire l’os en code safe, sandboxer les applis natives et formaliser le peu de code natif qui reste dans la HAL.









charon.G a écrit :



Je voulais pas répondre mais il y a pas mal de gens qui me font tenir des propos que je n’ai pas tenu et que je ne pense pas du tout..

Perso je regrette d’avoir quoter hadoken je visais qu’“une tranche d’intégriste en particulier.







ah là là là, jamais autant eu de quotes sur un de mes messages depuis fort longtemps <img data-src=" />



L’idée initiale était simplement de mettre en évidence que le code open source n’est pas la silver bullet qui permet d’avoir du code meilleur, vu que les processes de relecture de code ne sont souvent qu’une illusion sur le fait que l’on puisse s’assurer par soi-même que nos logiciels n’ont ni de bugs, ni de backdoors.



Dans le cas d’OpenSSL, très peu de personnes au final sont contributeurs actifs du projet, et mis à part eux pas grand monde n’a les compétences / le temps / la motivation par aller faire de la reclecture de code.



Cà pose aussi la question de la confiance (parfois aveugle) que l’on a dans certaines briques logicielles, FOSS ou proprio.



Pour ce qui est du FOSS d’ailleurs et puisqu’on en est à rectifier les mauvaises interprétation, je ne suis pas du tout un anti-libre. Je travaille avec du proprio principalement (univers .Net), mais :




  1. je suis totalement pour davantage d’open source dans le .Net (Mono, Moonlight, et maintenant Xamarin grâce à Miguel De Icaza notamment)

  2. bien évidemment même avec du proprio on intègre régulièrement de l’open source. Et encore une fois “intégration” est totalement différent de “vol” ou “profiter” ; intégrer = respecter scrupuleusement les licences (i.e. par exemple acheter une licence pour avoir le même binaire d’un code FOSS mais qui ne soit plus soumis à la GPL car non intégrable sinon), et participer dans la mesure du possible à l’amélioration des produits.

    Aller pour finir, j’ai moi même participé au libre bien plus que beaucoup ici je pense (4-5 projets sf.net, 2-3 sur codeplex, patches fournis à différents projets….etc.).





    Il faut juste avoir les yeux ouverts sur ce qu’est réellement le libre, et notamment sur le fait que la relecture du code anti-bugs/backdoors est davantage une promesse théorique que quelque chose de concret effectué sur les tous les projets (imaginez bien que ce ne soit pas le cas sur un truc aussi important qu’OpenSSL, alors sur les autres….).









hadoken a écrit :



Il faut juste avoir les yeux ouverts sur ce qu’est réellement le libre, et notamment sur le fait que la relecture du code anti-bugs/backdoors est davantage une promesse théorique que quelque chose de concret effectué sur les tous les projets (imaginez bien que ce ne soit pas le cas sur un truc aussi important qu’OpenSSL, alors sur les autres….).







Je suis d’accord et c’est d’ailleurs la première chose qu’on apprend en gestion de projet.

Si tu demande une chose à plus d’une personne, tu peux être sûr que personne ne se chargera de la faire car tout le monde pensera que son voisin l’a fait.

C’est un peu le même principe, tout le monde pense que son voisin a relu le code et qu’il est donc fiable









sepas a écrit :



On est d’accord <img data-src=" />

Par contre, je vois très peu de boite qui prennent du libre dans l’optique de faire évoluer un produit. La plupart veulent réduire au maximum le développement.





Oui, tout dépend de l’activité.



Après, le ressenti vient essentiellement de nos expériences respectives.



En tant que développeur, je vois essentiellement des boîtes qui veulent faire évoluer leurs produits.









ActionFighter a écrit :



Oui, tout dépend de l’activité.



Après, le ressenti vient essentiellement de nos expériences respectives.



En tant que développeur, je vois essentiellement des boîtes qui veulent faire évoluer leurs produits.





Ceci explique cela :)

Par contre, là où je vois beaucoup de développement, c’est dans les outils de CRM, ERP, sur tout ce qui est application métier.

Par exemple, énormément de code SAP

J’en vois beaucoup aussi sur les intranet/extranet

Sur de la bureautique par contre, pas du tout









sepas a écrit :



Ceci explique cela :)

Par contre, là où je vois beaucoup de développement, c’est dans les outils de CRM, ERP, sur tout ce qui est application métier.

Par exemple, énormément de code SAP

J’en vois beaucoup aussi sur les intranet/extranet

Sur de la bureautique par contre, pas du tout





<img data-src=" />



Et dans les CRM/ERP/ et autres applis de gestion, la plupart des boîtes choisissent des progiciels de gestion intégrés proprios avec licences+support, et paient des consultant pour les adapter et les faire évoluer, des formations hors de prix pour apprendre à faire des choses “basiques”



Ce qui est pour moi dont c’est le métier, une hérésie surtout financière.



Sur le logiciel sur lequel je bosse en ce moment, je dois développer un truc dans un langage proprio, et je n’ai accès à aucune doc, parce que le service de développement ne veut pas la fournir “pour des raisons de sécurité”, et c’est le seul moyen de développer les fonctionnalités que je dois mettre en place <img data-src=" />



Je me contente donc d’exemples de code fournis en standard et par d’autres consultants…..



Avec de l’open-source, j’aurais déjà fini ce que j’avais à faire depuis longtemps <img data-src=" />









sepas a écrit :



D’où l’importance d’avoir une base fiable.



Ce que dit Charon, c’est que si l’OS est conçu pour être safe (la sandbox en est un bon exemple), moins il y a de risque.

La sandbox peut-être buggué mais elle évoluera, les bugs seront corrigés comme pour le reste.

Mais le gros avantages, et que tout ce qui sera au dessus sera safe.



Sans Sandbox, tu multiplies les risques.



Personne n’affirme qu’il est possible d’avoir 0 bugs mais il est possible de les diminuer avec un OS bien pensé.











charon.G a écrit :



C”est déjà bien meilleur en terme de sécurité. Pour sortir d’une sandbox il faut une faille d’escalade de privilege il y en a rarement dans les faits. Dans le futur tu peux aussi te passer de runtime, écrire l’os en code safe, sandboxer les applis natives et formaliser le peu de code natif qui reste dans la HAL.







Oui oui ok ok.

Non c’était surtout sur l’aspect “on ne peut pas faire confiance en l’humain” (ce qui n’est pas faux hein).

Que les sandbox et autres permettent d’avoir quelque chose de plus safe, très certainement, je vous fais confiance là-dessus… je n’en sais que trop rien en fait.

Ce que je voulais surtout signifier, c’est l’argument du “on ne peut pas faire confiance en un humain du coup, hop, sandbox et ça roule” que je trouvais “décalé/bizarre” : la sandbox est aussi codée par un humain.









malock a écrit :



Oui oui ok ok.

Non c’était surtout sur l’aspect “on ne peut pas faire confiance en l’humain” (ce qui n’est pas faux hein).

Que les sandbox et autres permettent d’avoir quelque chose de plus safe, très certainement, je vous fais confiance là-dessus… je n’en sais que trop rien en fait.

Ce que je voulais surtout signifier, c’est l’argument du “on ne peut pas faire confiance en un humain du coup, hop, sandbox et ça roule” que je trouvais “décalé/bizarre” : la sandbox est aussi codée par un humain.





L’intérêt c’est clairement d’avoir des bases saines, et de concentrer toutes les difficultés tout en bas de la pile (qui nécessitent beaucoup d’expérience, d’analyse, de tests…etc.) à un seul endroit, dans cette base.



Une fois ce travail effectué, il faut juste mettre à jour régulièrement la base pour corriger les quelques bugs (il y en aura toujours bien évidemment), mais tout ce qui est construit par dessus ne bougera pas et bénéficiera au fil du temps des diverses amélioration de ce qui est fait dessous (sécurité, performance, fiabilité…etc.).









Impli a écrit :



Pourquoi ne pas envoyer le pass hashé au serveur qui se chargera de le hasher à nouveau, mais en incluant cette fois le salt. (…)

C’est une méthode que j’utilisais il y a quelques temps. (En utilisant du SHA-2)









David_L a écrit :



C’est une bonne solution (…)







Petite question à ce sujet: dans cet exemple, il faut alors hasher côté client? Donc en utilisant genre JS ou un truc du genre?

Et ensuite le re-hasher + salage en PHP pour le comparer à la BDD?









Impli a écrit :



J’ai du mal m’exprimer.



Quand je parle de modifier le hash, je parle de modifier légèrement le hash que l’on enverrai au serveur de façon à ce que si le hash est cassé, le pirate ne récupère pas le vrai mot de pass.

Après oui, le hash est toujours le même pour un pass donné. Mais là n’est pas là question.



Et si, le serveur reconnaîtra. Puisque, bien sûr, on ajoute le salt sur le hash modifié.

Au final la comparaison reste la même qu’avec le hash classique, on évite juste qu’un mec récupère le pass si le hash est cassé.







Si je récapitule:



Bob est le serveur. Alice a un compte sur le serveur.



Son mot de passe n’est pas stocké, uniquement un hash salé.



Bob, le serveur, envoie à Alice un sel à usage unique.



Eve peut intercepter le sel.



Alice hashe son mot de passe avec le sel. Elle envoie son hash à Bob, Eve récupère le hash.



Bob ne peut pas en l’état vérifier le hash.



Une autre solution:



Bob stocke un hash du mdp. Il génère un nouveau sel. Il envoie à Alice la suite de tous les sels. Là Alice hashe son mot de passe avec la suite des sels.



La question que je me pose. Avec la suite des sels, Eve ne peut-elle pas envisager une attaque ?



Mais bon, si on pouvait abandonner les mdp et passer au paires de clés )))






puisqu’il nécessite une composante aléatoire qui ne doit être connue que du serveur : le « salt ».



Si je dis pas de conneries, en théorie le hash, le salt, la méthode de hashage, tout ça pourrait être public sans pour autant rendre le mot de passe vulnérable.

Bien sûr ça dépend du mot de passe, la première chose qu’un attaquant va faire étant une recherche par dictionnaire et si le mdp s’y trouve…

C’est bien pour ça qu’on préconise un bon mot de passe, càd un mot de passe long avec des caractères spéciaux.

évidemment l’idéal c’est un bon salt (càd très long et donc pas sur 32 bits…), une méthode de hashage bien lente et un mdp bien long avec des caractères non basiques.

Pour moi le salt ne sert qu’a éviter les rainbow tables, ou tables en tout genre.









jrbleboss a écrit :



Ça reste quand même à des années lumières d’une faille qui permet de l’exécution de code.







De nos jours, il est plus facile de provoquer une exécution de code avec PHP qu’avec C++.



Et voila pourquoi : En PHP il existe la commande eval() dont beaucoup de programmes font usage et qui permet d’exécuter un code à partir de données. Si un hacker arrive à modifier les données qui vont à la commande eval, ils peuvent exécuter le code de leur choix.



En C++ en revanche, on ne peut pas executer aussi facilement des données. S’il était possible par le passé de profiter d’un dépassement de mémoire tampon pour tenter d’injecter du code, c’est beaucoup plus difficile aujourd’hui avec les protections NX Bit et ASLR.



L’exécution native a beaucoup amélioré sa sécurité avec le temps et je pense que beaucoup de programmeurs n’en prennent pas conscience.





<img data-src=" />





La dessus, sincèrement je suis très sérieux. Il n’est pas très compliqué d’éviter les pointeurs en C++ ou de les restreindre à des classes manipulatrices. C’est une simple question de style de programmation.



Penses tu qu’un gars qui as fait une école de programmation ne sait pas faire cela ?





Je ne doute pas que tu sois un programmeur de génie, mais mon propos est général. J’ai plaisir à utiliser du C/C++ tout autant que du C#/Python/Haskell, mais il ne faut pas se mentir, tout le monde fait des erreurs et certains langages en permettent beaucoup plus que d’autres, c’est indéniable.





En même temps, c’est toujours très facile de limiter les problèmes en diminuant les possibilités. C’est un peu comme si on ne mettait plus de moteur dans les voitures pour empêcher les accidents.



En C++, on peut très bien programmer sans utiliser de pointeurs (ou en restreignant leur usage à des fonctions précises et contrôlées).



Y avait t’il vraiment besoin d’inventer des langage pour enlever des possibilités ?



Et concernant d’autres langages de programmation qui apportent des paradigmes différents, ils apportent évidement leur intéret et pourront être choisi en fonction des besoins d’un projet.





Je suis absolument d’accord. Je pense néanmoins, qu’il y a énormément de code qui n’a aucune valeur à être en C et pourrait être dans un langage plus sûr. Sûr dans le sens où une manipulation mémoire directe en C n’est souvent pas justifiable.





Je suis globalement d’accord. Mais par expérience, je sais qu’ il n’est pas toujours possible de prévoir à l’avance les besoins d’un programme.



C’est pourquoi les outils polyvalents évitent aussi parfois beaucoup de soucis : qui peut le plus, peut le moins. Un projet utilisant un langage polyvalent ne se retrouvera jamais bloqué par une limitation.



Par contre, je ne suis pas d’accord de qualifier C/C++ de langage “non sûr” dans la mesure ou il est parfaitement possible d’utiliser un style de programmation sécurisé en C/C++.



Faut t’il vraiment traiter les programmeurs comme des toutous auquel on met une espèce de laisse pour les forcer à utiliser un style de programmation précis ?





Outre le niveau de compétence, il me semble qu’aujourd’hui, on n’utilise pas assez les outils qui sont à notre disposition. Un langage comme Ada ou Haskell ont des compilateurs qui vérifient des contraintes beaucoup plus poussées qu’en C/C++/C#/Java. Pourquoi ce priver de cela ? Parce qu’on est trop des roxxors du code et on n’en a pas besoin ? <img data-src=" />





J’ai toujours pensé que la diversité des langages informatiques était positive parce que chaque langage apporte ses forces et faiblesses.



C’est pourquoi je suis contre la logique de certains éditeurs qui vont vers la tendance à restreindre des plateformes à un seul langage ou à un type de langage (langages managés par exemple).



Pour autant, il ne faut pas oublier les raisons du succès de C/C++ qui tient à la polyvalence inégalée de ce langage dont les énormes possibilités permettent de remplacer une palanquée de langage et d’outils.



Ce langage a d’aillerus beaucoup évolué depuis ses débuts : formalisation beaucoup plus poussée et vérifications plus pointilleuses pour éviter justement les erreurs bêtes (certains se souviennent du C d’il y a 25 ans qui ne vérifiait à peu près rien). Et récemment, ajout de certaines possibilités venues des langages fonctionnels.



Évidement, je suis d’accord avec toi qu’il existe des langages qui apportent des avantages particuliers. Mais ils ont aussi le plus souvent d’autres inconvénients qui limitent leur utilisation à des besoins précis. C’est particulièrement le cas des langages fonctionnels.





J’ai jamais dit que cela allait tout régler. C’est juste qu’il y a beaucoup de cas où utiliser du C ne se justifie plus aujourd’hui.





Tous les logiciels n’ont pas besoin des l’ensemble des possibilités de C++. Et le choix d’un langage optimal sera toujours fonction du projet.



Pour autant, je trouve amusant de choisir un langage pour la raison qu’il vous interdit d’utiliser certaines possibilités.



Comme si les programmeurs étaient devenus si bêtes au point de ne pouvoir se fixer des règles eux même et choisir un style de programmation sécurisé sur un outil polyvalent.





On a jamais le beurre et l’argent du beurre. Il ne faut pas rêver. Ce n’est pas pour rien que les trains, avions, fusées, missiles, etc… ne sont pas codés en C, mais principalement en Ada.





De tous les langages, C/C++ est certainement celui qui est le mieux parvenu à concilier des exigences différentes et contradictoires. Et d’avoir réussi l’exploit de concilier de la programmation de couches basses comme de la programmation pour les couches hautes.



Tu peux intégrer de l’assembleur directement dans ton code tout autant qu’utiliser un style de programmation sécurisé. Ce langage est le couteau suisse de la programmation.



On peut vouloir utiliser des outils moins puissants. Mais la question qu’il faut se poser est : pourquoi ?



Pour ma part, j’ai toujours choisi un outil en fonction des possibilités qu’il m’offre, pas de celles qu’ils m’enlève.





Et dans pas mal de cas, je sacrifierais volontiers 10% de performances et la garantie de ne pas avoir d’erreurs aussi bêtes.





En utilisant le style de programmation qui va bien, tu n’aura jamais aucun problèmes de dépassement de mémoire tampon.



Il est évident que même un bon programmeur peut faire des erreurs. Mais s’il a choisi un style de programmation adapté, elles ne passeront pas.





Oui, tout autant qu’en assembleur tu peux faire la même chose qu’en C++.

La différence c’est 100x fois plus de chance d’avoir des bugs, un temps de développement bien plus long, etc…





En même temps, l’assembleur reste absolument irremplaçable dans certains cas de figure.



La encore, C/C++ est le langage qui permet le mieux cette intégration.









hadoken a écrit :



ah là là là, jamais autant eu de quotes sur un de mes messages depuis fort longtemps <img data-src=" />



L’idée initiale était simplement de mettre en évidence que le code open source n’est pas la silver bullet qui permet d’avoir du code meilleur, vu que les processes de relecture de code ne sont souvent qu’une illusion sur le fait que l’on puisse s’assurer par soi-même que nos logiciels n’ont ni de bugs, ni de backdoors.







Non, ce n’est pas une illusion. Pour que des gens puissent vérifier le code, il faut que le code source soit disponible. Mais le fait que ce soit un avantage majeur ne garantit pas pour autant d’obtenir un code parfait.





Dans le cas d’OpenSSL, très peu de personnes au final sont contributeurs actifs du projet, et mis à part eux pas grand monde n’a les compétences / le temps / la motivation par aller faire de la reclecture de code.





La, tu poses un vrai problème.



La question est bien de savoir si les ressources dont un projet dispose sont à la hauteur de son importance en matière de sécurité.



Je pense que le futur sera d’organiser des sources de financement et de contrôle par le biais des pays pour améliorer ces projets d’utilité publique.



Car il est bien évident que les enjeux de sécurité sont stratégiques pour les pays eux même. Une seule entreprise ou un groupe limité de personnes ne pourront y répondre.





Cà pose aussi la question de la confiance (parfois aveugle) que l’on a dans certaines briques logicielles, FOSS ou proprio.





En même temps, il est aussi plus facile de sécuriser convenablement une brique de sécurité centrale que des dizaines. Chaque logique a ses avantages et inconvénients.





Pour ce qui est du FOSS d’ailleurs et puisqu’on en est à rectifier les mauvaises interprétation, je ne suis pas du tout un anti-libre. Je travaille avec du proprio principalement (univers .Net), mais :




  1. je suis totalement pour davantage d’open source dans le .Net (Mono, Moonlight, et maintenant Xamarin grâce à Miguel De Icaza notamment)





    La réalité montre que cette logique ne mène à rien. Mono sera toujours à la traîne par rapport aux produits Microsoft.



    Et la question de la liberté d’un code se complique de la question des brevets dont le problème est qu’il est difficile d’évaluer facilement la menace potentielle sans éplucher des milliers de brevets par des compétences spécialisées… ce qui revient de fait extrêmement cher.





  2. bien évidemment même avec du proprio on intègre régulièrement de l’open source. Et encore une fois “intégration” est totalement différent de “vol” ou “profiter” ; intégrer = respecter scrupuleusement les licences (i.e. par exemple acheter une licence pour avoir le même binaire d’un code FOSS mais qui ne soit plus soumis à la GPL car non intégrable sinon), et participer dans la mesure du possible à l’amélioration des produits.





    C’est paradoxalement l’une des source de financement des entreprises qui font du logiciel libre. Ce qui explique le succès de la licence GPL qui est plus rentable pour les entreprises qui font du logiciel libre que la licence BSD.





    Il faut juste avoir les yeux ouverts sur ce qu’est réellement le libre, et notamment sur le fait que la relecture du code anti-bugs/backdoors est davantage une promesse théorique que quelque chose de concret effectué sur les tous les projets (imaginez bien que ce ne soit pas le cas sur un truc aussi important qu’OpenSSL, alors sur les autres….).





    Peut t’on conclure que la présence de failles suppose que le code n’est ni relu, ni vérifié ?



    Si la faille a été débusquée, c’est bien parce que quelqu’un l’a trouvée et donc que quelqu’un a vérifié le code.



    Et vous me direz que cette faille était présente depuis un certain temps. C’est juste que la complexité de tels projets fait qu’une telle faille peut échapper pendant un certain temps, même a des dizaines de relecteurs.



    Mais pas éternellement non plus, ce qui prouve bien l’intérêt de la logique.









Loufute a écrit :



Petite question à ce sujet: dans cet exemple, il faut alors hasher côté client? Donc en utilisant genre JS ou un truc du genre?

Et ensuite le re-hasher + salage en PHP pour le comparer à la BDD?







Le JS est une des solutions oui.

Ensuite tu envoies un premier hash au serveur qui fera un salt puis un second hash (en PHP ou autre) pour ensuite faire une comparaison classique avec la DB.









Vser a écrit :











Tu m’excuseras d’avoir tronqué ton message. C’était par pure lisibilité.



Donc en gros, tu résumes assez bien la chose.



Pour reprendre ton exemple, Eve peut effectivement tenter (et même réussir une attaque). Le pourcentage de chance étant relativement réduit (de par les hashs consécutifs et le salt).

Mais sa portée est aussi limité. Si Alice utilise le même mot de pass pour plusieurs comptes, Eve ne peut pas s’en servir.

(Et il ne faut pas se voiler la face. Nombre d’users ont le même mot de pass pour une dizaine de comptes différents).



Pour conclure, et comme je l’ai dit quelques posts auparavant, le but n’est pas de rendre l’échange de pass entre client & serveur impossible à pirater.

Il s’agit simplement de :




  1. chiffrer le pass afin de rendre le traitement des données plus complexes à analyser. (cas d’un MiM sans connexion chiffrée)

  2. empêcher l’attaquant de se servir d’un même mot de pass pour accéder aux divers comptes de l’user.





    (Et effectivement, un système de clé serait sans doute bien plus efficace)









    zoonel a écrit :



    Si je dis pas de conneries, en théorie le hash, le salt, la méthode de hashage, tout ça pourrait être public sans pour autant rendre le mot de passe vulnérable.

    Bien sûr ça dépend du mot de passe, la première chose qu’un attaquant va faire étant une recherche par dictionnaire et si le mdp s’y trouve…

    C’est bien pour ça qu’on préconise un bon mot de passe, càd un mot de passe long avec des caractères spéciaux.

    évidemment l’idéal c’est un bon salt (càd très long et donc pas sur 32 bits…), une méthode de hashage bien lente et un mdp bien long avec des caractères non basiques.

    Pour moi le salt ne sert qu’a éviter les rainbow tables, ou tables en tout genre.







    C’est bien là où je veux en venir.

    Si ton pass est correctement hashé et salé (ça me donnerait presque faim toussa), le fait qu’il soit rendu public ne serait, au mieux, qu’un contre-temps.

    Une attaque par brute force, et même par rainbow table aurait bien moins de chance d’aboutir.

    Mais comme tu le dis, tout dépend également du mot de pass. Et au vu des stats, ce n’est pas gagné. Surtout quand on voit certains sites limiter les pass en longueur, caractères spéciaux, chiffres, etc etc …

    Mais même dans le cas d’un pass bien foutu, pas mal de dev’ envoie les pass en clair ou utilise des hash/chiffrement connu pour leur faiblesse (que ce soit par soucis de rapidité du traitement ou par économie des ressources).









Vser a écrit :











J’ai voulu éditer ma réponse, mais un trop tardivement.

Ton exemple (et ta conclusion) ne viendrait pas de cet article ? &lt;3









jrbleboss a écrit :



On a jamais le beurre et l’argent du beurre. Il ne faut pas rêver. Ce n’est pas pour rien que les trains, avions, fusées, missiles, etc… ne sont pas codés en C, mais principalement en Ada.







Mon grain de salt <img data-src=" />



Je ne sais pas pour le reste, mais dans les avions, et dans les systèmes les plus critiques (DAL A), on n’utilise pas que de l’ADA, et même parfois pas du tout. Dernier exemple en date sur un avion pas encore sorti: le code manuel est 99% en assembleur, 1% en C. Sur un autre projet de même criticité, on avait moit’ moit’ C et ADA. Après, ces codes sources sont testés à 100% (couverture fonctionnelle et structurelle, toutes les conditions étant testés), c’est plutôt là que tout se joue. Voili voilou ^^









NeoSlaaV a écrit :



Mon grain de salt <img data-src=" />



Je ne sais pas pour le reste, mais dans les avions, et dans les systèmes les plus critiques (DAL A), on n’utilise pas que de l’ADA, et même parfois pas du tout. Dernier exemple en date sur un avion pas encore sorti: le code manuel est 99% en assembleur, 1% en C. Sur un autre projet de même criticité, on avait moit’ moit’ C et ADA. Après, ces codes sources sont testés à 100% (couverture fonctionnelle et structurelle, toutes les conditions étant testés), c’est plutôt là que tout se joue. Voili voilou ^^







C’est aussi une question de style de programmation.



On peut très bien utiliser du C et encapsuler toutes utilisation de pointeur dans une fonction qui fait du bound check. On peut également multiplier les vérifications de cohérences. Et le tout, comme tu le dit, avec des procédures draconiennes de vérification du code.