Journal Heartbleed : petit best of des journalistes

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
70
11
avr.
2014

Aaah, pas facile d'écrire un article sur un sujet aussi technique que le récent bug sur OpenSSL, baptisé Heartbleed, quand on est journaliste généraliste. Forcément, ça donne des erreurs et approximations dans l'article final, ce qui ne manque pas de nous font osciller entre le rire gras et le désespoir, nous, techniciens. Petit tour d'horizon du best of des journalistes sur Heartbleed.

Avant de commencer, notons que je passerai sur les trop nombreuses occurrences de l'adjectif crypté et ses variantes, qui permettent d'estimer d'un clin d'œil la qualité des articles. Pourquoi faut-il encore rappeler que crypter n'est pas synonyme de chiffrer ?

Commençons soft. L'article du monde déclarait hier que le bug était nommé ainsi car il touchait le cœur d'OpenSSL. C'est faux, mais bon c'est mignon, et surtout ça a été corrigé depuis. Noble initiative, surtout que c'est la seule correction d'erreur flagrante que j'ai pu constater.

Parmi les confusions récurrentes, on trouve celle entre le protocole et son implémentation. Ainsi, 20 Minutes déclare qu'« un problème sur les protocoles utilisés pour protéger le trafic a été corrigé en urgence ». Non, OpenSSL n'est pas un protocole. Le Figaro déclare que « la bibliothèque de cryptage (sic) OpenSSL est utilisée […] par des protocoles d'emails (SMTP, POP, IMAP) et des réseaux privés (VPN) ». Non, ce ne sont pas les protocoles qui utilisent OpenSSL, mais certaines de leurs implémentations. D'ailleurs, on ajoute en général un S au nom du protocole quand celui-ci utilise une couche de chiffrement, ce qui est oublié ici. Gizmodo va plus loin, et nous décrit SSL/TLS comme « une clé cryptographique ». Non : là, pour le coup, c'était un protocole.

Le Figaro encore, dans un autre article, décrit OpenSSL comme « un logiciel d'encodage ». Comment-ça, le codage et le chiffrement, c'est pas la même chose ?

Passons rapidement sur ceux qui, ayant survolé rapidement le sujet, s'emmêlent les pinceaux dans les numéros de version concernés. C'est pourtant simple : les versions touchées sont la 1.0.1 jusqu'à 1.0.1f inclus (mais pas 1.0.1g !), et 1.0.2. Et pourtant, Zataz indique que la vulnérabilité est présente sur « OpenSSL 1.0.1 (non pacthé (sic), ou 1.0.2) » (et ils n'ont pas l'excuse de la faute de frappe pour « pacthé », puisqu'ils réécrivent « pacth » plus loin). Le Figaro encore : « parmi les serveurs utilisant OpenSSL, seuls ceux équipés de la version 1.0.1 sont touchés. ». Sauf si ceux-ci ont déjà été mis à jour. Mais bon, je chipote là, avançons.

Il y a ceux qui essayent de faire peur. Ça vend bien, en général. Ainsi, Gizmodo vous regarde droit dans les yeux et vous annonce : « Il y a pléthore de sites qui utilisaient la version branlante, mais comme ces attaques ne laissent aucune trace… il n’y a aucun moyen de savoir combien ont été réellement attaqués. Si vous êtes utilisateur de l’un d’eux, vos informations d’identification sont maintenant dans la nature. » Carrément ! Ça fait sacrément peur, dites donc ! Certes, le bug est critique, mais récupérer des informations à partir de celui-ci n'est pas trivial : elles doivent être en mémoire. Si je ne me suis pas connecté à un site depuis un moment, il est assez peu probable qu'un attaquant potentiel ait pu récupérer quoi que ce soit. Et comme ils le disent eux-mêmes, on ne sait pas (encore ?) si l'attaque était connue et exploitée auparavant. Zataz, encore, fait de même : « Bilan, les protocoles SSL et TLS, qui sont les "sécurités" de l'Internet, deviennent le cheval de Troie de pirates ayant de gros, très gros moyens. ». Brrr. Il faut sûrement de très gros moyens pour exploiter une faille dont les nombreux exploits publics ne nécessitent guère plus qu'un simple ordinateur pour être utilisés. En plus SSL/TLS est « la » sécurité d'Internet, et elle vient de tomber. Tous aux abris !

Et puis il y a ceux qui s'emmêlent franchement les pinceaux. Le Parisien nous dit que « parmi les informations susceptibles d'êtres récupérées par les pirates figurent le code source (instructions pour le microprocesseur) ». Hum. Analysons cette déclaration, en prétendant n'avoir pas vu la confusion classique entre code source et code compilé. Le bug ne permet que d'accéder aléatoirement à certaines parties du tas, ne laissant un accès possible ni au code source (à moins que le logiciel place son propre code source en mémoire, mais pourquoi ?), ni à la section .txt de la mémoire du processus utilisant la librairie. Cela ne laisse donc accès ni à l'un ni à l'autre des deux éléments Mais ce serait quand même drôle d'utiliser un bug pour récupérer le code source de logiciels open source ! (Bon, certes, OpenSSL utilisant une licence non virale, il est tout à fait possible que des logiciels propriétaires l'utilisent, sans parler de l'accès éventuel à des fichiers de config. Mais de toute façon, c'est faux. Ne chipotez pas.)

Mais revenons à l'article de Zataz, qui mérite un paragraphe à lui seul. Car un article qui dès le titre établit une relation possible avec la NSA ne peut augurer que du bon. Vers la fin de l'article, l'auteur se lance dans une accusation contre Cloudflare : « il est intéressant de regarder le doigt qui dénonce la faille… plus que le problème. […] L'auteur de l'annonce, Cloudflare […], a diffusé l'information avant que la moindre correction ne soit proposée pour la version 1.0.2. ». Oui, sauf que Cloudflare n'est nullement l'auteur de l'annonce, et que la version 1.0.2 d'OpenSSL est un version Beta, qui n'a pas à être utilisée en production…
Mais je vous ai gardé la meilleure phrase de l'article pour la fin : « Le problème vise la bibliothèque Heartbleed d'OpenSSL. ».

Et puis il y a le Figaro. Je l'ai déjà cité à plusieurs reprises, mais son article contient encore de sacrées perles :

  • il décrit OpenSSL comme une « bibliothèque de cryptage en libre accès ». Traduction originale d' open source ? Pourquoi pas, après tout !

  • « la faille existerait depuis décembre 2011 et aurait été accrue par la mise à jour d'OpenSSL en mars 2012. ». « Accrue », c'est à dire ? La vérité est que le commit introduisant le bug a été effectué en décembre 2011, et la version d'OpenSSL l'utilisant est sortie en mars 2012. Si la situation est effectivement devenue plus grave à cette date, la faille est restée la même. L'auteur a mal interprété l'article de PCinpact qu'il prend comme source.

  • « Il est difficile d'affirmer si les grands acteurs du web ont été attaqués ou non, mais un site tente de répondre à cette question. » L'outil permet de tester si un site est toujours vulnérable, ce qui est bien loin de nous dire s'ils ont effectivement été attaqués.

  • « Fixed OpenSSL, la version corrigée du protocole, a été mise au point mais doit désormais être déployée. » aptitude install fixed-openssl ?

  • Et le meilleur pour la fin : « Cependant, les nombreux sites restés fidèles au traditionnel système de cryptage SSL/TLS sont épargnés »

PS : Je n'ai pas lu tous les articles sur le sujet, on doit sûrement trouver encore bien d'autres bourdes.
PS2 : Et avec des articles si précis et pertinents, je vous laisse imaginer la qualité des commentaires associés.
PS3 : Il y a aussi évidemment des articles corrects sur le sujet dans la presse généraliste, ne généralisons pas trop vite.

  • # Pourtant c'est simple !

    Posté par  . Évalué à 10.

    XKCD arrive à expliquer très simplement et compréhensible par n'importe qui la nature de la faille : http://xkcd.com/1354/

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Pourtant c'est simple !

      Posté par  (site web personnel) . Évalué à 10.

      Titre de l'image

      "La première sécurité est la liberté"

      • [^] # Re: Pourtant c'est simple !

        Posté par  . Évalué à 5.

        Heartbleed is a catastrophic bug in OpenSSL:
        "The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users."

        Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory. This means that anything in memory—SSL private keys, user keys, anything—is vulnerable. And you have to assume that it is all compromised. All of it.

        "Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.

        Bruce Schneier.

    • [^] # Re: Pourtant c'est simple !

      Posté par  (site web personnel) . Évalué à 3.

      J'adore le : "… Files for IP 375.381.283.17 …" dans la troisième case :-D

      kentoc'h mervel eget bezan saotred

  • # non pacthé

    Posté par  . Évalué à 9.

    non pacthé

    C'est quand il n'y a pas impacth, c'est ça ?!?
    ====>[]

  • # Entendu à la radio

    Posté par  . Évalué à 10.

    Si vous utilisez un site avec une URL qui commence par HTTPS, vos données sont exposées.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Entendu à la radio

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 11 avril 2014 à 17:21.

      C'est incroyable !
      Cette faille est franchement l'une des plus graves qu'on ait jamais vu, mais certains médias trouvent quand même le moyen de la faire paraître pire encore. Alors que franchement, au niveau sensationnel, en s'en tenant aux faits on est déjà super servi sans avoir à pousser le bouchon.

    • [^] # Re: Entendu à la radio

      Posté par  . Évalué à 10.

      Je sais. Depuis cette annonce, je m'assure que mes mots de passe sont envoyés systématiquement en clair, bien trop peur de me les faire gauler par un exploit sur cette faille!
      Je vais lancer une extension HTTPSnowhere pour protéger les gens!

  • # Logiciel plaçant son propre code source en mémoire

    Posté par  . Évalué à 4.

    à moins que le logiciel place son propre code source en mémoire, mais pourquoi ?

    Au hasard, PHP ? :)

    J'ai testé un des nombreux PoC qui trainent sur le net depuis le début de la semaine sur mon webmail sur une install non mise à jour. On peut apercevoir, parmi d'autres informations plus ou moins critiques, (je laisse chacun juge sur ce point) des bouts du code PHP du webmail :)

    • [^] # Re: Logiciel plaçant son propre code source en mémoire

      Posté par  (site web personnel) . Évalué à 2.

      Je me suis justement posé la question des langages interprétés. Est-ce qu'ils placent leur propre code en mémoire, ou juste un bytecode qui en est issu ? (ou rien du tout)
      Est-ce que les bouts de code que tu as constatés ne venaient pas d'un eval() ? (ou fonction équivalente)

      • [^] # Re: Logiciel plaçant son propre code source en mémoire

        Posté par  . Évalué à 4.

        Tout ce qui passe par la mémoire à un moment ou un autre ( avant l'attaque bien sur) peut être dévoilé.
        Or pour faire du bytecode à partir d'un php, il faut le mettre en mémoire avant.

        • [^] # Re: Logiciel plaçant son propre code source en mémoire

          Posté par  . Évalué à 2.

          Tout ce qui passe par la mémoire du processus !
          Je ne connais pas assez l'architecture des serveurs web, mais est ce que, par exemple, apache, fait tounrer dans le même process, la compilation du php, leservicede page web et le protecole de communication, en particulier les algos de chiffrement ?
          Tout ce qui est exécuté dans des processus séparés devrait à priori ne pas devoir être impacté, non ?

          • [^] # Re: Logiciel plaçant son propre code source en mémoire

            Posté par  (site web personnel, Mastodon) . Évalué à 1.

            Tout dépend de la manière dont tu as branlé le bouzin.

            Dans une pile classique LAMP, PHP est un module Apache : une sorte de librairie qui est chargée en mémoire d'Apache. SSL/TLS peut être géré par mod_ssl. Dans ce cas, on peut avoir le problème.

            Maintenant, ceci est une architecture naïve, qui ne sera pas utilisée pour des applications bancaires. Pour les applications bancaires, tu auras d'abord un proxy SSL, puis Apache, puis PHP en FCGI par exemple. Les espace mémoire étant séparés, seules les données dans la mémoire du proxy SSL seront corrompues. C'est déjà pas mal, mais ça permet d'éviter l'exposition du code source et du paramétrage de PHP.

        • [^] # Re: Logiciel plaçant son propre code source en mémoire

          Posté par  (site web personnel) . Évalué à 6.

          Mais qui voudrait piquer du code php?

  • # CloudFlare

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Si, c'est bien CloudFLare qui a publié trop tôt sur la bogue, avant que tout le monde ne soit prêt https://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities

    • [^] # Re: CloudFlare

      Posté par  . Évalué à 4.

      Si le CVE était publié avant, c'est pas le post de blog de cloudflare qui était trop tôt…

    • [^] # Re: CloudFlare

      Posté par  . Évalué à 4.

      Ce post est daté du 7 avril à 11h du matin, mais s’agit-il de l’heure UTC ou de l’heure locale au siège de CloudFlare (heure du Pacifique, soit UTC-8) ?

      Si c’est l’heure UTC, alors c’est 5 heures avant que les développeurs d’OpenSSL publient leur propre annonce et poussent le commit corrigeant la vulnérabilité sur leur dépôt public. Dans ce cas, c’est irresponsable.¹

      Si c’est l’heure du Pacifique, c’est 19 heures UTC, soit deux heures après la publication par les développeurs d’OpenSSL.

      ¹ Et présenter ça comme un bon exemple de « responsible disclosure » est, euh, comment dire…

  • # Philosophie

    Posté par  . Évalué à 10. Dernière modification le 11 avril 2014 à 14:48.

    Moi je pense qu'il faudrait interviewer Alain Finkielkraut à ce sujet, ce serait intéressant d'avoir l'avis de ce brillant académicien, spécialiste du nain ternette. ça pourrait faire une bonne dépêche pour un vendredi.

  • # Apparemment, c'était connu

    Posté par  . Évalué à 4.

    Et comme ils le disent eux-mêmes, on ne sait pas (encore ?) si l'attaque était connue et exploitée auparavant.

    https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013

  • # Conspiration

    Posté par  (site web personnel) . Évalué à 2.

    Car un article qui dès le titre établit une relation possible avec la NSA ne peut augurer que du bon.

    Bon, c'est vrai que j'évite de tomber dans la parano quand je peux. Mais là, en l’occurrence, il est difficile de croire que la NSA n'avait pas cette info et n'en avait pas profité.

    Tiens, d'ailleurs, on commence à voir des articles qui accusent la NSA d'avoir su.

  • # Chipotons

    Posté par  . Évalué à 2.

    […] la mémoire du processus utilisant la librairie.

    Les librairies, c'est pour les logiciels qui appellent des fonction payantes ?

    La revue de presse est intéressante mais l'analyse tient de l'enc…hiffrement de louchmèmes.

    Cette signature est publiée sous licence WTFPL

  • # Codage et chiffrement

    Posté par  (site web personnel) . Évalué à 2.

    Le Figaro encore, dans un autre article, décrit OpenSSL comme « un logiciel d'encodage ». Comment-ça, le codage et le chiffrement, c'est pas la même chose ?

    C'est la même chose, le chiffrement est juste un codage qui n'est connu que des parties impliquées ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.