Faille Heartbleed - OpenSSL

**ticNFA** · 11/04/2014, 15h24

Envoyé par GTSLASH

Si une erreur si grave arrivait 3 fois chez Microsoft ce serai fini pour eux car la confience n'y serait plus pour personne. Et la je parle de Microsoft pas d'une petite boite national. Ca arrive a une boite si petite elle serait direct finie.

Que ce soit libre ou pas le développement doit être bien organisé. Et la il y a eu un gros problème dans celui de OpenSSL. Ca aurait du etre decouvert plus tot. Il y a des outils pour ca et des test unitaire et ous le reste.

Quel est la conséquence pour le(s) développeur(s) d'OpenSSL ? aucunes c'est gratuit.Ils n'ont de compte a rendre a personne car par définition c'est libre.

Si ca arrive chez Microsoft ou Oracle les investisseurs vont leur tomber dessus et des tetes vont tombées. C'est le principe de la responsabilités. Et dans l'OS personne n'est vraiment responsable car il n'y a pas d'argent derriere.

Et puis les faits sont la. La plus grosse faille de la decenie a ete provoquee par de l'OS. Et quand je discute avec mes clients eux ca les interesse et le prenne en compte

La bonne blague. C'est moi qui a été naïf de croire que tu l'étais, tu lis que ce que tu veux bien.

MS et Oracle sont responsables devant les investisseurs en effet et devant eux seuls. Tu peux rajouter la NSA. Dans le libre, on rend des comptes à la communauté. Les développeurs du libre ont intérêt que leurs projets fonctionnent sinon à quoi bon perdre du temps ?

Un intervenant a rapporté le cas d'Ariane, on pourrait ajouter l'interface de Windows 8, plus triviale. Et avec ce qu'on sait désormais grâce à Snowden, ces propos sont simplement risibles du fait de la collusion NSA et des grands de l'info. Ils peuvent tout se permettre.

Mais on pourrait sortir de l'info en citant les multiples entreprises très très responsables devant leurs investisseurs : Tepco, BP, Total (AZF), on continue ? Les banques et les subprimes.
Je n'aimerais pas être un de tes clients avec une vision aussi biaisée des faits.

**GTSLASH** · 13/04/2014, 11h12

Je n'essayai pas de vous convaincre. Loin de la. Mais de vous confronter a la realitée des faits pour voir quels excuses vous trouverez. C'est fait. Et j'ai pu voir quels arguments vous faite valoir. Ca m'aidera dans mon travail

.

Et on le sait tous c'est jamais noir ou blanc c'est toujours gris.

Bon dimanche a vous tous.

**Town Ground** · 14/04/2014, 02h54

Pour ce qui est de la "réactivité" la faille en question date d'il y a ... deux ans! Donc si pendant les deux dernières années ton compte en banque n'a pas été vidé, tu peux bien attendre encore un peu avant de changer de mot de passe...

Un article à ce propos en cliquant ici...

Combien d'autres failles?

**Neckara** · 14/04/2014, 07h38

Bonjour,

Tes sources disent pourtant :

Cette faille daterait d'il y a deux ans et aurait été découverte la nuit du lundi 7 avril au mardi 8 avril 2014.

Donc à partir de la découverte de la faille à sa correction, tout a été très réactif.

Après on ne peut pas corriger des bugs qu'on ne connaît pas et avoir un logiciel avec 0 bugs est impossible. De même ce n'est pas parce qu'un bug existe qu'on est au courant de son existence.

**tomlev** · 14/04/2014, 10h36

Envoyé par Town Ground

Pour ce qui est de la "réactivité" la faille en question date d'il y a ... deux ans! Donc si pendant les deux dernières années ton compte en banque n'a pas été vidé, tu peux bien attendre encore un peu avant de changer de mot de passe...

Pendant 2 ans, le bug existait, mais la plupart des gens l'ignoraient. A partir du moment où tout le monde connait l'existence du bug, sa nature, et la facilité avec laquelle il peut être exploité, combien de temps crois-tu que les script kiddies vont attendre pour s'attaquer aux serveurs encore vulnérables ?

**centreurope** · 14/04/2014, 13h18

merci pour l'article, qui n'est pas rassurant mais réaliste...
Pour une info sur la faille et les recommandations d'action, il y a http://www.heartbleed.fr en français, qui reprend les infos d'Heartbleed.com, mashable, etc.

**sneb5757** · 14/04/2014, 15h36

Ce lien évoque le principe de reverse heartbleed. Rapidement, il s'agit de créer un serveur SSL malicieux qui envoie une requête heartbeat à un client pour récupérer 64 kB de sa mémoire.

On peut y trouver un lien vers un outils python permettant de tester les clients ( navigateur ,curl, wget .... )

**forthx** · 14/04/2014, 16h19

Qu’en pensez-vous ?

C'est pas joli joli.
La conspiration face au concept: "c'est open source donc c'est plus sûr car revu par beaucoup de contributeurs" laisse songeur.(Ce qui est sur, c'est ce c'est injuste de mettre ca sur le dos de la communauté, cf. licence)
Après il y a plein de failles découvertes tout les jours, plus au moins sérieuses (les applets java en ont pris pour leur grade il y a pas si longtemps). Alors ok celle la est particulièrement croustillante ! Il va falloir que les professionnels réagissent vite pour limiter la casse.
Ce qui me parait sage? couper les serveurs le temps de patcher, mais c'est évidement délicat, malgré le fait que plus l'application est critique, plus les risque d'être ciblé sont grand.
Dans le croustillant il y a ca aussi : http://thehackernews.com/2014/04/Oba...y-Exploit.html

Mais pour répondre a la question : "HeartBleed, l’une des pires failles de sécurité d’Internet ?"
Je pense que non. pour moi, la pire faille, c'est celle qui est exploitée et qu'on ne connais pas. C'était peut être HeartBleed les deux dernières années mais ca ne l'est plus.

**Aiekick** · 14/04/2014, 18h57

si l'opensource c'est le mal alors que pensez du closed source surtout depuis qu'on sait que la NSA a installé des backdoor dans moults logiciel closed-source ?

Et au moins une fois la faille réparée on sait de source sure qu'elle est réparée alos que dans les soft closed-source, il peuvent dire ce qu'ils veulent...

**guillaume07** · 15/04/2014, 00h27

en 35 ans de carrière c'est la première fois que je vois pareil bug!

Invité · 15/04/2014, 14h55

Pas toujours facile de planifier un donwtime pour patcher le(s) équipement(s) impacté(s)...

En attendant, vous pouvez carrément bloquer le heartbeat du handshake TLS avec la règle iptable suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP

Il faudra bien sûr adapter le --dport si ce n'est pas de l'https et vérifier qu'il n'y a pas d'impact fonctionnel sur votre appli... A tester donc évidemment avant toute mise en prod...

Steph

**Pierre GIRARD** · 18/04/2014, 15h14

Au niveau local, si quelqu'un réussi à se connecter sur mon PC et qu'il arrive à récupérer des mots de passes ??? je ne vois pas trop l’intérêt, vu qu'il est déjà sur mon PC.

Et, Je ne sais pas pour les autres, mais que peut-on faire si sa banque (par exemple) est victime du bug et que quelqu'un y pirate ses coordonnées bancaires ?

A part faire peur ...? Mais bon, la peur organisée, j'ai déjà connu ça, ça s'appelait : Le "Bug de l'an 2000"

**forthx** · 19/04/2014, 01h52

Envoyé par Pierre GIRARD

Au niveau local, si quelqu'un réussi à se connecter sur mon PC et qu'il arrive à récupérer des mots de passes ??? je ne vois pas trop l’intérêt, vu qu'il est déjà sur mon PC.

On peu se connecter a un pc sans pouvoir tout faire.
En fait c'est surtout valable si ton pc n'offre pas de service externe, ou que tu a un routeur qui bloque la communication de ces services avec l'exterieur. Si ton pc offre une connexion ssh, ou fait du service web https ET que tu utilise pour ces services openSSL (Ca fait beaucoup de si mais on est probablement plusieurs ici dans ce cas de figure), alors ta machine cours un risque si tu ne fait rien.

**Pierre GIRARD** · 19/04/2014, 09h06

Je ne risque rien dans mon cas, mais la question était : que risque-t-on exactement si on correspond à ces critères ? A part que quelqu'un puisse lire mon courrier ou accède à mes factures ou à mes déclarations d’impôts ? Et que ferait-on de tout ça ?

**Arsene Newman** · 25/04/2014, 17h22

Et si OpenSSL était l'incontournable bible de la sécurité ?
A l'image de la monoculture Windows au sein du marché des PC, analyse d’un expert

Et si Heartbleed avait affecté les systèmes d'exploitation Microsoft, qui dominent largement le marché des ordinateurs ? Quelles auraient été les conséquences d'une telle faille ? C'est la question posée par Dan Geer directeur de la sécurité informatique de In-Q-Tel.

Pour rappel, le règne de Windows au cours des dernières années a démontré qu'une monoculture n'est pas sans danger et la découverte d'une faille n'implique pas la fin de son exploitation, car cela demande beaucoup d'efforts et de moyens pour fixer toutes les machines affectées.

Geer estime que Heartbleed est symptomatique des larges problèmes rencontrés au cours de l'ère post-Windows actuelle : ère où les entreprises comptent sur différents équipements et logiciels, même si de légers bugs de ces derniers (non critiques) peuvent perturber grandement le fonctionnement d'une entreprise.

Pour celui-ci, « Heartbleed est instructif », même si « son déploiement n'est pas suffisamment large pour parler de monoculture à l'échelle d'Internet, la faille a un coût très substantiel ».

Alors, si OpenSSL était la bible des bibliothèques de sécurité, cela pourrait créer des conditions idéales pour l'apparition d'une faille logicielle dite « de mode commun », où différents systèmes se baseraient sur un élément défaillant commun (un élément matériel ou logiciel), ce qui aurait des conséquences désastreuses.

« Internet, en tant que tel, a été conçu de manière à résister à des pannes aléatoires, il n'a pas été conçu pour résister à des pannes bien ciblées », a déclaré Geer, avant de rajouter que « La faille Heartbleed peut être imputée à la complexité : toutes les normes de l'Internet ont été étendues avec des options compliquées qu'aucune personne ne connaît vraiment. De même, elle peut être imputée à l'insuffisance des investissements : la relecture du code open source est rarement financée et dans le cas contraire jamais durablement. Enfin, elle est à attribuer à la mauvaise planification : des déploiements à grande échelle comportant des fonctions critiques, mais sans aucun mécanisme de correction des failles ».

Mais alors quelle est la solution ? Pour Geer, cela ressemble à 3 approches différentes : tout d'abord multiplier la coopération entre les différents acteurs d'Internet (privé/public, open source/propriétaire) pour améliorer la sécurité et détecter les éventuelles failles de sécurité de certains éléments de base largement utilisés sur Internet, ou encore faire la chasse aux bugs en appliquant des politiques très strictes dans le développement logiciel pour limiter leurs apparitions en amont, enfin la troisième et dernière solution envisagée serait de développer des systèmes en mesure de fixer automatiquement leurs failles, systèmes qui seront issus d'un domaine en plein essor, l'informatique autonome (Autonomic computing).

Source : Billet de blog de Dan Geer

Et vous ?

Qu’en pensez-vous ?

**abriotde** · 28/04/2014, 23h57

Tout système est susceptible d'avoir des failles et il est prouvé que l'Open-Source est de ce point de vue très sur. Tout informaticien sait qu'un système sûre est un système à jour. Il existe aujourd'hui des moyens simple de mettre a jour ses logiciels d'une ligne de commande dans le monde de l'Open-Source. Mais surtout le logiciel propriétaire n'a pas intérêt a faire connaitre que son logiciel a une faille (Apple est expert dans ce domaine) et donc n'incite pas a une mise a jour (qui est d'ailleurs souvent payante, c'est pourquoi les entreprises sont réticente a faire évoluer leur parc fonctionnel et stable (cf Windows XP)). Ainsi si l'éditeur de logiciel a corrigé une faille, elle mettra longtemps a être diffusé, ce n'est pas le cas de l'Open-Source.
Le point faible de l'Open-Source, c'est le temps de mise a jour des librairies qu'utilise un logiciel compte tenu de manque de moyen. Mais c'est surtout vrai sur les petits logiciel avec une petites communauté Open-Source. Aujourd'hui Linux, Apache, PHP, OpenDNS sont les logiciels dominant internet et ils sont Open-Sources. Il est très difficile de les prendre en défaut car ils ont de grosses communauté a l’affût des failles. Ils sont a la base de Google, Oracle, Facebook, eBay... alors ils ont les moyens.

**Simara1170** · 29/04/2014, 10h40

Pourquoi on a viré sur un débat Libre/MS?
Pour revenir en arrière
quota approximative:

Si microsoft avait 3 fois une erreur comme ça, il aurait déjà fermé

:
-Windows 95?
-Windows Millenium?
-Windows Vista?
-Windows 8?

Tiens, j'suis à 4, et j'ai pas compté les failles trouvé sur les OS réputés solides de chez MS, la faille dans les fichiers de police sur Xp, c'était quand même bien mignon...
Et puis l'AV de Microsoft, une seule solution -> clic droit -> supprimer, ce truc est une vraie passoire, et passe juste en standard sur ta bécane OEM pour te forcer l'achat d'une suite logicielle entièrement MS. Puis c'est pas comme si MS avait contourné la loi avec Windows 8:
On ne peut plus tatouer les disque durs? Bah c'pas grave, aller on tatoue la CM (secure boot toussa toussa)

Faut arrêter de taper sur OpenSSL parce qu'il y a eu une faille. Y'a eu une merde dans un code open source? Et après? Y'en a jamais eu dans du code proprio? J'aurais tendance à dire qu'il y en a plus: ton code est fermé, alors tu peux programmer comme un gros sale, tu t'en fout, personne pourras le lire, et si un bug est remonté, tu t'en bat le zob tout autant, puisque t'auras déjà fait ton CA dessus, regarde avec Win8: "Vous voulez le retour du bouton démarrer? Ca feras 200€, parce que ça sera sur Win9" (perso, j'ai classic shell et ça m'a coûté 2 minutes de mon temps pour l'installer et le paramétrer...)

Bref, met la faille en regard d'un autre problème bien connu: le bug de l'an 2000: bawi tout est parti en vacances parce qu'on avait pas jugé utile de coder la date sur 4 chiffres...

Il y a eu une faille importante, et il y en aura d'autres à venir...

Petite aparté, sur les DDOS: il est quasiment impossible de se prémunir d'une attaque DDOS bien menée... Et puis une DDOS, c'est pas automatisée? Petite astuce, tape LOIC anonymous sur le Gogole, j'suis sûr que tu trouveras un petit programme adapté dans le cas d'attaque communautaire, et pour les pc zombies, c'est vrai que je vois bien le hacker se faire chier à véroler un par un ses 10k zombies...

**TheGreyMustache** · 30/04/2014, 20h40

Entre le vrai risque et la grosse farce, mon coeur hésite un peu. Concernant le codage des dates auquel tu fais allusion, il ne faut pas oublier que nombre de systèmes avaient été conçus à une époque que tu n'as peut être pas connue, quand la mémoire et le stockage étaient limités. Cela n'a rien à voir avec le sujet en cours... me concernant, dans les années 80, on utilisait des logiciels qui codaient l'année sur 1 caractère. Cela était volontaire et pas un bug comme le soit disant bug de l'an 2000.

**Simara1170** · 01/05/2014, 11h31

Là, en l'occurence, je faisais référence à une société d'assurance en Suisse qui stocke sur AS400 depuis des lustres (puisque ça continue encore) avec des bandes journalière etc, bref la mémoire était pas franchement un souci pour eux, et pourtant quand les dev' ont fait remonté que le passage à l'an 2000 pourrait être source de bug, le chef de service en poste ne les avait pas cru... Résultat, toutes les applications sont partis en carafe, et la dev' team s'est tapé des journées de 15h pour remettre ça d'aplomb... Ca fait bien d'être appelé à une heure du matin le 1er janvier, quand t'es un poil bourré et qu'on te dit, faut aller bosser y'a plus rien qui marche...
Le bug de l'an 2000 en est un sans en être un: il y a des soucis parce que les dev' se disaient "mon appli sera redéveloppée dans les 5 ans de toutes façon..." C'est le provisoire qui a dure qui a tout envoyé péter... Enfin, remarque aujourd'hui, rien de nouveau sous le soleil, le provisoire qui dure en informatique, c'est la base du métier pour certains -_-'

**Pierre GIRARD** · 01/05/2014, 13h28

Personnellement, j'ai vécu ce "Bug de l'an 2000" en astreinte, comme pratiquement tout le service. En fin de compte, il ne s'est rien passé pour nous (sur des applications et serveur UNIX). Mais, dès le lendemain, on a quand même appris que des problèmes avaient existé ailleurs.

Par contre, les services développement travaillaient sur ce problème depuis plus d'un an et étaient sensés avoir par avance résolu tous les problèmes potentiels.

Donc :