Journal La course à la sécurité

Posté par  (site web personnel) .
Étiquettes :
0
18
fév.
2008
Le site Distrowatch propose un très intéressant tableau comparatif pour voir le temps de réaction des principales distributions lors de la récente alerte de sécurité du noyau Linux.

Quel a été le délai entre la publication générale de l'alerte sur tous les sites (le 11 février) et la mise à disposition du patch correcteur par les différentes distributions ?

Distribution => Delay
Debian GNU/Linux => +0 hours
Fedora => +8 hours
Slackware Linux => +12 hours
Mandriva Linux => +19 hours
Frugalware Linux => +21 hours
openSUSE => +23 hours
rPath Linux => +26 hours
Red Hat Enterprise Linux => +27 hours
Ubuntu => +27 hours
CentOS => +37 hours

Le site Distrowatch souligne néanmoins qu'il ne faut pas surinterpréter ces chiffres. Certaines distros proposent le support de diverses architectures alors que d'autres ne sont disponibles pour les CPU les plus répandus. Il est évident que le temps de réaction ne sera pas le même.
De même les grosses distros commerciales (Red et Suse) testent certainement plus longtemps leurs patchs car les clients qui payent n'aiment pas les problèmes lors des mises à jour.

L'article de Distrowatch indique également que certaines distros (Arch ou Zenwalk par exemple) n'ont toujours pas proposé le patch correcteur à leurs utilisateurs.

  • # ArchLinux...

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

    Doit y'avoir comme un bug pour arch : le noyau 2.6.24 patché était dans les tuyaux le dimanche 10 février au soir...
    J'ai fait le test avec l'exploit : il ne fonctionne plus sur ma machine depuis cette mise à jour.

    \_o<

    • [^] # Re: ArchLinux...

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

      Ladislav s'est basé sur les alertes de sécurité des distros.
      Peut-être que Arch patche ses noyaux mais ne publie pas d'alerte de sécurité ? (auquel cas c'est mieux que pas de patch mais c'est quand même pas terrible).

      • [^] # Re: ArchLinux...

        Posté par  . Évalué à 5.

        La dernière mise à jour du noyau archlinux date du 10 février et un communiqué en première page du site officiel est diponible à l'adresse http://www.archlinux.org/.

        Il ne s'agit pas, en effet, d'une alerte de sécurité en tant que t elle. La mise à jour devait, initialement, être une "remise à niveau" du noyau vers une version plus récente. Cette remise à niveau s'est accompagnée du patch correctif de la récente alerte de sécurité du noyau Linux. Il s'agit d'un très chanceux hazard que la date de mise à jour du noyau concordait avec l'application d'un correctif de sécurité important du noyau.

        Il est vrai que la référence au correctif est discret dans le communiqué.

        • [^] # Re: ArchLinux...

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

          Sous Arch, dès la faille connu, le paquetage kernel26 fût mis à jour et distribué. C'était le noyau 2.6.24.1 avec le prepatch 2.6.24.2.

          Que ArchLinux ne fasse pas de patch de sécurité est normal, la mise à jour suffit.

          • [^] # Re: ArchLinux...

            Posté par  . Évalué à 2.

            Il y a un point que je ne comprend pas bien : cette mise à jour a-t-elle été proposée comme une mise à jour "classique" ou bien comme une mise à jour qui faisait également office de mise à jour de sécurité ?

            BeOS le faisait il y a 20 ans !

            • [^] # Re: ArchLinux...

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

              Comme une mise à jour classique.

              Bien que je comprends pas la différence entre les deux, c'est une mise à jour, après c'est que littérature !

              • [^] # Re: ArchLinux...

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

                La différence, c'est qu'une mise à jour classique (surtout du noyau), tu peux prendre ton temps pour la faire. Une mise à jour de sécu, en général, tu agis avec plus de célérité.

                • [^] # Re: ArchLinux...

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

                  Tu pars du principe que ArchLinux fonctionne comme toutes les autres distributions, ce qui n'est pas le cas.

                  Nous faisons des mises à jour de noyau à chaque changement mineurs, cad :
                  * 2.6.23.1
                  * 2.6.23.2
                  * 2.6.23.3
                  …
                  * 2.6.24.1

                  Pour archlinux une mise à jour est un un élément normal, donc lorsque le correctif fût dispo, le mainteneur a diffuser le noyau 2.6.24.1-2 (où -2 est propre à Arch) avec le prepatch du noyau 2.6.24.2.
                  Effectivement, on télécharge et installe tout le noyau.

                  En espérant avoir éclairé ce point sombre sur la compréhension du fonctionnement de ArchLinux.

                  • [^] # Re: ArchLinux...

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

                    Ce n'est pas une raison. Une mise à jour de noyau, ça nécessite un redémarrage du serveur. Si le serveur est critique, on peut retarder ce redémarrage jusqu'au prochain week-end / vacances par exemple. Mais si la faille de sécurité est encore plus critique, alors on assume de couper le service pendant 5 minutes, le temps d'un redémarrage (ou alors on met en place un serveur de backup pour la transition, etc.). Reste que pour savoir si la faille est critique ou pas, il faut communiquer dessus.

                    • [^] # Re: ArchLinux...

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

                      Sauf que archlinux est une distribution desktop.
                      Tu utiliserais une distribution bleeding edge pour un serveur critique ?

    • [^] # Re: ArchLinux...

      Posté par  . Évalué à 1.

      > le noyau 2.6.24 patché était dans les tuyaux le dimanche 10 février au soir...

      Comme pour Fedora et Red Hat et Debian (celui-ci avait de l'avance) et d'autres.
      C'est un chose de pousser un patch dans un cvs, c'est une autre de tout construire ,synchroniser sur les mirroirs et faire l'annonce.

      Un exemple pour F8 :
      http://koji.fedoraproject.org/koji/buildinfo?buildID=35322
      Started Sun, 10 Feb 2008 14:23:20 MST
      Completed Sun, 10 Feb 2008 18:15:31 MST
      Pour i686, x86_64, ppc, ppc64 (les architectures supportées par Fedora).
      Donc c'était en download (les binaires) depuis 10 Feb 2008 18:15:31 MST. Mais pas sur les mirroirs, sans annonces, etc.

  • # Pas compris

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

    Je trouve étrange de lire "Certaines distros proposent le support de diverses architectures alors que d'autres ne sont disponibles pour les CPU les plus répandus" alors que d'après le tableau, debian qui tourne sur un paquet d'architectures arrive première avec "0 hours".

    Bref, je sais pas ce qu'on peut vraiment tirer de ces chiffres, mais cette phrase ne m'a pas l'air pertinente.

    • [^] # Re: Pas compris

      Posté par  (Mastodon) . Évalué à 2.

      cette phrase ne vise pas debian.

      Si elle existait "officiellemen" sur autant d'architectures que debian, je ne crois pas que slackware aurait été la 3ème plus rapide étant donnée le nombre de mainteneur restreint.

    • [^] # Re: Pas compris

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

      C'était juste une mise en garde pour éviter les trolls.
      Frugalware par exemple ne supporte que les x86 et x86_64 alors que Red Hat Enterprise Linux support beaucoup plus d'archis.

    • [^] # Re: Pas compris

      Posté par  . Évalué à 1.

      Je l'ai interprété comme une attaque subtile contre Ubuntu : Ubuntu, dérivée de Debian et qui supporte moins d'architectures a eu besoin de 27h pour fournir un correctif.

      Je suis paranoïaque ?

  • # Debian rules !

    Posté par  . Évalué à 2.

    Ce n'est pas encore vendredi, mais j'arriverais pas à retenir mon troll jusque là :
    Debian rules !

    Bon ok, en dehors du troll :
    0 heures , c'est quoi ce chiffre ?
    Ca voudrais dire que le correctif serait parru dans l'heure ? impressionnant.

    Doit-on en conclure que Debian c'est mieux que %%Votre distrib préférée%%, (je pense que oui :) ).
    Sachant que l'ecart entre Debian et son suivant est de 8 heures, ne doit on pas y voir de la précipitation du côté de Debian ? (je pense que non)

    • [^] # Re: Debian rules !

      Posté par  . Évalué à 2.

      0 heures , c'est quoi ce chiffre ?
      Ca voudrais dire que le correctif serait parru dans l'heure ? impressionnant.

      Pour les failles critiques les "vendors" sont generalement prevenus a l'avance. Generalement, ca se passe en 3 temps (sans compter la premiere etape ou le projet apprend qu'il a un joli trou de secu ;))
      1. Annnonce de la failles aux security officers/maintainers, avec souvent un correctif
      2. Quand les principaux acteurs sont prevenus/prets, une date et une heure sont choisies pour l'annonce publique.
      3. une fois annoncee, tout le monde applique le fix (commits dans les repos, mise a jour des packages, etc...)

      Note: il peut s'ecouler plusieurs jours/semaines/mois entre la phase 1 et 3.

    • [^] # Re: Debian rules !

      Posté par  . Évalué à 6.

      0 heures , c'est quoi ce chiffre ?
      Ca voudrais dire que le correctif serait parru dans l'heure ? impressionnant.

      Non, c'est n'est pas ça.

      Sur la page c'est bien marqué que la faille a été découverte le 8 et corrigée à partir du 11.

      À partir de ce moment là Debian est pris comme temps de référence. Et le nombre d'heure des autres distribs, c'est le temps en plus qu'elles ont mis à corriger.

      Un peu comme dans une course automobile, la première au vainqueur correspond le temps qu'il a mis. Pour les autres, on met un différentiel par rapport au premier.


      J'aurai préféré qu'on mette le temps de l'annonce en référence, ce serait plus parlant. On verrai bien qu'entre 3 jours et 3 jours et 8 heures, la différence n'est pas si grande que ça. Par contre entre 3 jours et 5 jours, ça commence à faire beaucoup. (Pas pour dénigrer Debian, c'est ma distrib et je suis content de voir qu'elle a été la plus réactive. Juste parce que je trouve que ça aurait été plus parlant).


      Une autre chose aussi. Dommage que Distrowatch soit à ce point imprécis. Ils donnent des dates et des heures, pas pas de fuseau horaire de référence... En général ça ne m'étonne pas de cerains habitants des États Unis (pas tous hein, je ne généralise pas) qui sont relativement ignorant qu'il y a quelque chose en dehors de leur frontières, mais là... Même aux USA il y a plusieurs fuseaux horaires. Ils devraient le savoir non ?

      Bref on n'est pas le 8/02 partout dans le monde en même temps, et pour les heures de référence, c'est encore pire... D'autant que leurs commentaires sont exprimés en GMT. Probablement le fuseau retenu pour ce comparatif ?

      • [^] # Re: Debian rules !

        Posté par  . Évalué à 2.

        Un peu comme dans une course automobile, la première au vainqueur correspond le temps qu'il a mis. Pour les autres, on met un différentiel par rapport au premier.

        Si seulement le systeme sous-jacent pouvait etre aussi simple que ca...

        /me retourne a la réecriture de son projet actuel, poetiquement appelé "FOMTeamClient"

      • [^] # Re: Debian rules !

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

        >>> En général ça ne m'étonne pas de cerains habitants des États Unis (pas tous hein, je ne généralise pas) qui sont relativement ignorant qu'il y a quelque chose en dehors de leur frontières, mais là...

        Ladislav (l'auteur de Distrowatch) vit à Taiwan je crois.

    • [^] # Re: Debian rules !

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

      ça veut surtout dire que les debianneux bossent le dimanche car ils ont pas de probléme avec la drh ou l'inspection du travail /o\

      ( non, j'ai pas dit qu'ils ont aucune vie, pas du tout )

    • [^] # Re: Debian rules !

      Posté par  . Évalué à -1.

      > Debian rules !

      C'est pour un bug seulement !

      > Doit-on en conclure que Debian c'est mieux que %%Votre distrib préférée%%, (je pense que oui :) ).

      Pour ce bug, oui.

  • # Slackware

    Posté par  . Évalué à 2.

    Je suis en 11.0 et je n'ai pas encore vu l'ombre du patch ...
    Patcher la dernière stable, c'est bien, mais qu'en est-il des autres ?

    Bon ok, le 2.6.17 fournit dans la 11.0 est dans extra/, ça n'empêche que l'install via NFS l'utilise ...

  • # Et Gentoo ?

    Posté par  . Évalué à 3.

    Pourquoi n'apparait-elle pas dans le classement ?

    Je sais bien qu'on ne peut pas y mettre toutes les distributions mais elle reste quand même assez répandue.
    La faille n'est pas encore corrigée ?
    Il y a eu un soucis de communication (pas de publication du correctif) ?

    • [^] # Re: Et Gentoo ?

      Posté par  . Évalué à 2.

      Les ebuilds (pour plusieur versions du noyau) avec le correctif ont été mis à jour le 11 vers 17h (selon cvs), donc à priori +3~4h

  • # un truc pareil pour les admins?

    Posté par  . Évalué à 1.

    Ce serait interessant/rigolo de voir combien de temps cela a pris en moyenne aux admins pour appliquer la mise a jour. Je sais pas pourquoi mais je soupconne que les endroits ou le trou etait problematique (c'est a dire dans un environnement multi-utilisateurs intensif) il fut corrige avec moins de celirite pour diverses raisons donc le fait qu'il est parfois dificile de rebooter, je pense aux grappes de calculs avec des jobs qui tournent depuis des jours voir des semaines, que pour l'ordinateur mono-utilisateur et donc la ou il ne sert a presque rien.

    • [^] # Re: un truc pareil pour les admins?

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

      Flinguer mon uptime pour un trou de sécu alors que je suis mono-utilisateur ? Jamais !

    • [^] # Re: un truc pareil pour les admins?

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

      Je pense qu'une grappe de calcul qui tourne depuis des semaines est plus que bien protégée d'internet. Sinon, le moindre gars passe par là, fait une fork bomb, et fout en l'air 3 moins de prévisions sur l'astéroide Paco Rabane...
      Nan, je pense que les admins de machines critiques sont de BOFH, et qu'ils ont bien raison...

      Bon, il y a certainement des cas problématiques (de mise à jour, pas d'admin) mais ca se règle très facilement... avec un BSD ^^

    • [^] # Re: un truc pareil pour les admins?

      Posté par  . Évalué à 1.

      Je travaille pour un hebergeur, faille corrigé le 11 dans la matinée (dès qu'on a ouvert nos mails et trouvé le patch).

Suivre le flux des commentaires

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