Journal Faille de sécurité critique dans le générateur pseudo-aléatoire de NetBSD 6.0

Posté par (page perso) . Licence CC by-sa
33
25
mar.
2013

C'est le syndrome OpenSSH de Debian qui frappe une nouvelle fois.
Du fait d'une parenthèse mal placée dans le code du fichier /src/sys/kern/subr_cprng.c, il s'avère que le générateur pseudo-aléatoire de NetBSD 6.0 est bien moins solide que ce qui était attendu.
C'est une manière polie de dire que sa sortie n'est pas assez aléatoire et qu'il faut d'urgence changer les clés SSH qui ont été générés avec ce noyau !

L'alerte de sécurité : http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2013-003.txt.asc
Un article de h-online : http://www.h-online.com/open/news/item/Weak-keys-in-NetBSD-1829336.html

Le problème est corrigé dans NetBSD Current et le fix sera disponible dans la furture version NetBSD 6.1.
Il est probable que les dégâts seront bien moins étendus que lors de l'affaire OpenSSH dans Debian car les systèmes NetBSD 6.0 ne sont sans doute pas très fréquents dans la nature.

  • # Des détails

    Posté par . Évalué à 6. Dernière modification le 25/03/13 à 16:03.

    Bonjour,

    Le bug reste sérieux mais ce n'est pas le même passif que le bug introduit dans OpenSSL par Debian,non? (je ne suis pas expert en sécurité).

    D'une part le bug Debian a couru pendant deux ans, avec une possibilité de génération de clés assez faible ( 25000 en gros selon la news).
    Si je lis le Netbsd Security Advisory, les systèmes de la version 6.0 générés avant le 27 Janvier 2013 sont impactés. La version 6.0 est sortie courant mi-octobre 2012. Ce qui fait une correction en moins de deux ans, si je ne m'abuse.

    Pour palier à ce problème de parenthèses mal placées, il est nécessaire d'installer un noyau contenant le fix construit après le 27 Janvier.

    Le Netbsd Security signale au pire la génération de clés de 32 bits sur certaines plate-formes, avec "plus a 32-bit cycle counter value, plus the name of the generator(an LWP ID for userspace, a fixed string for kernel consumers),plus stack noise for the remainder." Cette phrase, je ne la comprends guère, donc si quelqu'un la comprend ou a des explications à fournir ( ou des liens pertinents), je serai preneur.

    • [^] # Re: Des détails

      Posté par . Évalué à 4.

      Désolé de faire mon grammar n*zi, mais on dit "palier un problème".

      Un bon moyen pour s'en souvenir est de remplacer le mot par son sens originel : "recouvrir". On dira "recouvrir un problème", le faire disparaître.

      • [^] # Re: Des détails

        Posté par . Évalué à 10.

        Merci, je suis content d'être corrigé. Me redresser sur ce genre de fautes me forcera à une seconde relecture.
        D'autant plus que c'est "pallier un problème" et non "palier". "Palier" étant une plate-forme, un étage.

  • # outil de mesure ?

    Posté par . Évalué à 4.

    A quand un outil de vérification de ces générateurs aléatoires ?

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

    • [^] # Re: outil de mesure ?

      Posté par . Évalué à 3.

      A quand les devs noyau se mettront au TDD plutôt qu'à code hero ? ;)

      • [^] # Re: outil de mesure ?

        Posté par . Évalué à 1.

        A quand les devs noyau se mettront au TDD plutôt qu'à code hero ? ;)

        A peu près au même moment qu'ils se mettront à coder en le noyau en Ada(*) plutôt qu'en C?

        *: Non, Ada ne permettrait pas de trouver ce problème particulier, mais plein d'autre..

        • [^] # Re: outil de mesure ?

          Posté par . Évalué à 4.

          Le jour ou l'on recodera 12millions de lignes de code de C vers ada, en perdant tout l'historique et les corrections de bugs réalisées depuis 30ans, on aura forcément un truc plus stable.

          Faut pas non plus croire que coder en Ada supprime tout les bugs… D'accord c'est plus simple à prouver, mais c'est pas évident que recoder un noyau en Ada soit un bénéfice sinon à trés long terme (10ans ?). A moyen terme, des choses comme seL4 sont sûrement beaucoup plus prometteuses.

    • [^] # Re: outil de mesure ?

      Posté par (page perso) . Évalué à 10.

      • [^] # Re: outil de mesure ?

        Posté par . Évalué à 0. Dernière modification le 25/03/13 à 18:25.

        Tu peux aussi lire ce que les spécialistes pensent de Diehard :

        Oh, and I'm talking about serious tests here, not just dicking about with Diehard and the NIST tests.
        — David B. Thomas

        Plus bas, il explique que Diehard et NIST sont obsolètes dès qu’on a besoin de billions de nombres aléatoires, auxquels cas il faut recourir à Crush et BigCrush en sus. Pour des trucs pas sérieux comme la simple génération de clés, ce genre de tests importe peu.

  • # C'est peut-être con, mais…

    Posté par . Évalué à 1.

    Un noyau génère des clef SSH ? Uh ?

    • [^] # Re: C'est peut-être con, mais…

      Posté par . Évalué à 10.

      Non mais il génère des bits aléatoires, qui eux servent à SSH pour générer les clés. Et c'est bien la le problème. man 4 random

  • # Que les clefs SSH ?

    Posté par . Évalué à 10. Dernière modification le 25/03/13 à 21:29.

    C'est une manière polie de dire que sa sortie n'est pas assez aléatoire et qu'il faut d'urgence changer les clés SSH qui ont été générés avec ce noyau !

    Il y a une raison particulière pour laquelle SSH serait seul touché ? Moi dit comme ça j'aurai tendance à considérer toutes les clefs cryptographiques générés sur une machine ayant ce noyau comme faible.

    • [^] # Re: Que les clefs SSH ?

      Posté par (page perso) . Évalué à 2.

      Toutes les clefs générées en utilisant /dev/urandom. Peut-être que les autres bibliothèques utilisent /dev/random directement pour générer leurs clefs ?

      • [^] # Re: Que les clefs SSH ?

        Posté par . Évalué à 5.

        Ca me ferait un peu peur que quelqu'un utilise /dev/urandom pour des besoins cryptographiques. Je viens de regarder le code d'OpenSSH:

        Pour OpenSSH, il utilise arc4random et donc /dev/arandom.

        Pour OpenSSH portable il repose sur /dev/random. Il existe une possibilité d'utiliser PRNGd si il n'y a pas de /dev/random ou si on le choisi.

  • # Code snippet ?

    Posté par . Évalué à 5.

    Quelqu'un a-t-il compris cette histoire de parenthèse ? J'ai essayé de trouver le morceau de code en question, mais sans succès.

Suivre le flux des commentaires

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