Discussion :

[DotNetMatt]

Ces dernières heures, vous avez probablement entendu parler de cette faille de sécurité qui attaque en plein cœur la sécurité du Web : Heartbleed ("cœur qui saigne").

Elle touche OpenSSL et est présente dans la bibliothèque de chiffrement en version 1.0.1 et 1.0.2 bêta. La première étant aujourd'hui largement déployée, la découverte de cette faille a de quoi soulever des inquiétudes. Elle permet en effet à un attaquant d'accéder à des données sécurisées par TLS/SSL directement dans la mémoire du serveur, en récupérant les clefs. Cela aurait également pu impacter les certificats, pourtant réputés comme très sûrs.

Un ingénieur de Google, Adam Langley, qui a participé à la création du correctif, a quelque peu calmé le jeu sur Tweeter en indiquant qu'il n'avait pas réussi à récupérer les clefs, seulement un cookie.

Les géants du Web ont déjà appliqué le correctif, cependant les sites plus modestes ne sont pas encore tous immunisés. Les principaux éditeurs de logiciel font également leur maximum pour pousser le correctif chez leurs clients. Il est possible de vérifier si un site est vulnérable ou non en utilisant le site http://filippo.io/Heartbleed/.

La publication de cette faille de sécurité a eu lieu avant même que le moindre patch ne soit disponible, ce qui a provoqué une réaction très rapide des principaux acteurs du Web.

En attendant, il est recommandé d'être prudent lorsqu'un site utilise une connexion cryptée par SSL/TLS (url commençant par HTTPS). Changer de mot de passe n'est pas une solution, car celui-ci pourrait être récupéré via un site vulnérable lors du changement.

Si votre site est vulnérable, n'attendez pas pour appliquer le patch 1.0.1g sur vos serveurs. Il est disponible ici : http://www.openssl.org/source/
Il faut également déposer de nouvelles clés et renouveler son certificat de sécurité.

[sneb5757]

Je ne suis pas tout à fait d'accord sur le changement de mot de passe.

Certes cela ne règle pas le problème, et si le service sur lequel est changé ce dernier est encore compromis, le risque reste le même. Mais sur un service impacté et sur lequel la faille de sécurité a été corrigé ça a du sens.



Le problème est de savoir si oui ou non un service a été impacté. Ce qui m'inquiète un peu ce sont les banques qui ne sont pas franchement bavardes sur les problèmes de sécurité. Si un service ne communique pas comment savoir s'il faut changer le mot de passe ou pas ? J'ai hésité, mais j'ai quand même posté un message sur mon FB pour inciter mes amis à changer leur mot de passe de leur web banking et service stockant des données sensibles. Je pense également qu'il faudrait être vigilant ( je veux dire plus que d'habitude) les prochains temps sur les mouvements d'argent des comptes en banques. C'est peut être un excès de prudence mais ça ne me parait pas une mauvaise recommandation. Votre avis ?

Ensuite certes aucune clé privé n'a été récupérer apparemment, mais chez yahoo! de nombreux mot de passe ont fuité de leur serveur d'authentification.

[pmithrandir]

Si tu veux savoir, tu peux tester ta banque avec ce lien.
http://filippo.io/Heartbleed/

A priori la mienne est pas impactée.

En plus, si l'annonce a été faite hier matin dans les médias, l'update de open ssl était disponible 2 heures avant sur mon ordi. (distrib mageia) On peut donc espérer que les banques auront su réagir vite.

[Algo D.DN]

Je ne suis pas tout à fait d'accord sur le changement de mot de passe.

Certes cela ne règle pas le problème, et si le service sur lequel est changé ce dernier est encore compromis, le risque reste le même. Mais sur un service impacté et sur lequel la faille de sécurité a été corrigé ça a du sens.

Tout à fait d'accord, on ne peut pas demander aux utilisateurs de changer leurs pws si les serveurs (https donc sécurisés) restent vulnérables à cette faille...

Moi ce qui m’inquiète dans ce cas de figure (Heartbleed affectant OpenSSL) c'est la réactivité des éditeurs de logiciel pour patcher leurs solutions, surtout le temps de réponse à l'application du correctif, j'ose supposer que la réactivité est au rendez-vous pour les sites sensibles et les serveurs ayant normalement une bonne maintenance.

Quand à ceux pour qui la sécurité n'est qu'une notion abstraite

[dev14]

Bonjour,

votre lien de test assure que ma banque aussi n'est pas impactée. Mais qui me dit qu'elle n'a pas fait sa mise à jour il y a 1h, et qu'avant elle était concernée. Autrement dit, on devrait peut être changer nos mots de passe quand même?

Et pour d'autres sites (hébergés chez OVH) :

Uh-oh, something went wrong: write tcp ***********:****: broken pipe

Cela signifie que le diagnostic est impossible ou que la faille existe pour eux à votre avis?

Exemple aussi du site de pari en ligne : https://www.betclic.fr

[fredoche]

Merci pour la news DotNetMatt

C'est un peu l'effervescence autour de ce sujet

Bonjour,

votre lien de test assure que ma banque aussi n'est pas impactée. Mais qui me dit qu'elle n'a pas fait sa mise à jour il y a 1h, et qu'avant elle était concernée. Autrement dit, on devrait peut être changer nos mots de passe quand même?

Et pour d'autres sites (hébergés chez OVH) :

Uh-oh, something went wrong: write tcp ***********:****: broken pipe

Cela signifie que le diagnostic est impossible ou que la faille existe pour eux à votre avis?

Exemple aussi du site de pari en ligne : https://www.betclic.fr

Je ne sais trop que penser de ce site de test.

Concernant betclic, il est fort probable que ce soit un site servi par IIS, on y voit un cookie ASP.NET_SessionId
et si tu lis ici :
http://blogs.iis.net/erez/archive/20...d-and-iis.aspx
IIS ne serait pas affecté

Moi-même utilisant IIS7.5 sur 3 serveurs, j'ai testé toutes mes URLs servies en https parce que j'utilise différents certificats. La plupart ont répondu avec un "broken pipe " mais sur l'un d'eux ce testeur m'a remonté une lecture mémoire, uen seule fois, puis ensuite "broken pipe ". Donc ce site de test n'est peut-être pas totalement fiable, et il n'a rien d'officiel.

extrait de la FAQ du site en question :

broken pipe is also caused by the unaffected IIS server

[pmithrandir]

Pour moi c'est pourtant simple.

Tu testes :
- si c'est infecté, tu ne t'y connecte surtout pas
- sinon, tu change ton mot de passe par précaution(vu qu'ils sont clean ou ont résolu le problème)

[GTSLASH]

Donc si j'ai bien compris si je me connecte sur un site avec cette faille tous passera en clair ? Mot de passe, N° Carte de credit,...

C'est beau l'Open Source.

Je suis d'accord que la communautés peut être réactif et corriger rapidement ce genre de bug. Encore faut il que ca soit corrige plus rapidement qu'une firme tel que Microsoft, Google ou autre (permeter moi de douter mais bon soit)

Mais vous ne m'empecherez pas d'etre certain qu'il est plus facile de trouver une faille dans un logiciel dont on a le code source.

Si je me trompe une correction est vraiment la bien venue.

[Jimmy_]

Il faut relativiser , l'attaquant ne contrôle pas la zone mémoire qu'il va récupérer,
même s'il peut tenter l'attaque autant de fois qu'il veux, le résultat est aléatoire.

[sneb5757]

Oui mais dans le cas d'un serveur d'authentification avec des milliers d'authentification par minutes ça fait des ravages ( cf yahoo mail).

Je pense que le fait que ça soit aléatoire est encore pire. Il y'a aucun moyen de savoir ce qui a fuité ou pas. Juste constaté les éventuels dégâts.

[Invité]

C'est beau l'Open Source.
...

Oui, mais des problèmes il y en a partout libre ou pas...

Sinon pour Android ( et les ajouts constructeurs ) quelqu'un sait où on en est?

[GTSLASH]

Oui, mais des problèmes il y en a partout libre ou pas...

Oui je sais. Je vend moi même des logiciel et les problèmes arrive a tous le monde. C'est n'est pas ca que je met en cause. Je met en cause le fait que quand le code source est public il est plus facile de trouver des failles.

[sneb5757]

Ca va repartir en débat interminable en libre VS non libre mais il est préférable qu'une faille soit connu par un plus grand nombre et corrigé au plus vite , plutôt que la faille soit connue par seulement une poignée de hacker et exploité sur du plus long terme.

La sécurité par l'obscurité n'est pas ce qu'il y'a de plus efficace.

[Invité]

Je met en cause le fait que quand le code source est public il est plus facile de trouver des failles.

Ou plus facile à corriger aussi et sur un code propriétaire on ne peut pas mais les logiciels propriétaires sont victimes de pirates depuis des lustres.

Bref c'est l'humain derrière qui fait tout dans un cas comme dans l'autre.

[Algo D.DN]

Je suis d'accord que la communautés peut être réactif et corriger rapidement ce genre de bug. Encore faut il que ca soit corrige plus rapidement qu'une firme tel que Microsoft, Google ou autre (permeter moi de douter mais bon soit)
Mais vous ne m'empecherez pas d'etre certain qu'il est plus facile de trouver une faille dans un logiciel dont on a le code source.
Si je me trompe une correction est vraiment la bien venue.

Pour ma part je constate que sur deux distributions Libres Debian et Trisquel cette faille est déjà corrigé...

[GTSLASH]

oui. je ne me fais pas de tracas pour la correction des failles mais sur la découverte des failles. Quand tous le monde vois le code c'est plus facile d'en trouver. c'est principalement ca qui me fait peur dans l'Open Source. Surtout quand c'est dans le domaine de la sécurité.

[sneb5757]

J'ai du mal à comprendre cette crainte. Le but ce n'est pas de mettre les failles sous le tapis. Mais de les trouver et de les corriger.

Ceci dit il n'y a pas forcément besoin d'accéder aux codes sources pour trouver des failles. Vu le nombre de failles découverte ( zero day en plus)dans des produits microsoft, apple ou adobe ayant un code fermé on ne peut pas dire que la fermeture du code source empêche quoique ce soit.

[GTSLASH]

Si 100 personnes connaissent une faille et l exploitent pendant 1 an ça me donnera moins de risque que si 3 000 000 l'exploite 3 jours. Sans parler de la NSA etc

http://foxitsecurity.files.wordpress...ed-example.png

en trois jours ils ont pu en avoir des mots de passes et le revendre. Et en plus le script a ete publier et est donc accessible a tous le monde. Mois ca me fait peur en tous cas

Vu le nombre de failles découverte ( zero day en plus)dans des produits microsoft, apple ou adobe ayant un code fermé on ne peut pas dire que la fermeture du code source empêche quoique ce soit.

Mon avis est qu'un code ferme n’empêche pas la découverte de failles mais qu'un code ouvert la facilite

[GTSLASH]

Je doit avouer que ces arguments sont convainquant. Mais j'ai quand même difficile a croire que il y a publiquement des méthodes permettant a un hacker de prendre le contrôle ou de pirater des système comme Sql Server, Windows Server, etc

Qu'une simple recherche sur Google me permettrais de trouver un script ou autres pour prendre le contrôle d'un serveur/pc. Et ce alors que Microsoft ou autre soit au courant depuis des mois.

(Et ca me fais bien marrer cet histoire de point sur le forum j'en dormirais pas un forum c'est fait pour échanger des avis apprendre et discuter c'est pas un examen )

[GTSLASH]

Et apparemment ce bug dans OpenSSL date de 2 ans

http://windowsitpro.com/security/mic...re-not-so-much

This is a two year old bug that somehow went unannounced. The ironic thing is that it's the most recent versions of OpenSSL that are affected.

http://www.aidanfinn.com/?p=16322

The lesson here is simple: Building alleged enterprise-class software where no-one is responsible for trustworthy computing reviews is negligent. Who reviewed that code?

Mais c'est peut etre pas le bon endroit pour discuter de ca.