Journal Évaluation des risques de RHEL 4

Posté par  .
Étiquettes :
0
27
fév.
2008
Mark Cox (Director of the Red Hat Security Response Team ... entre autre) a fait un rapport sur les vulnérabilités de RHEL 4 pour les 3 premières années de RHEL 4 :
http://www.redhatmagazine.com/2008/02/26/risk-report-three-y(...)

Notons bien qu'une vulnérabilité même si elle n'est pas exploitable dans la configuration par défaut n'est pas "sous-estimée". Elle est comptabilisée. Par exemple par défaut Apache être installé (version serveur) mais n'est pas activé par défaut (les serveurs sauf ssh ne sont pas activés par défaut sur Red Hat/Fedora). Les failles d'apache sont néanmoins (et fort logiquement) comptabilisée. Même si par défaut ce n'est pas activé ou que la configuration par défaut n'est pas affectée, c'est comptabilisé. On ne sait pas si l'utilisateur va activer ou a modifié la configuration.
Idem pour SeLinux, etc. Les vulnérabilités sont comptabilisés même si elles ne sont pas exploitables.

Donc ne faites pas de comparaison avec OpenBSD... la sécurité n'est pas mesurée de la même façon.
  • # SIGTROLL

    Posté par  . Évalué à -3.

    Donc ne faites pas de comparaison avec OpenBSD... la sécurité n'est pas mesurée de la même façon.

    Range ton troll à deux francs CFA, OpenBSD n'a aucun besoin d'être comparé à quoi que ce soit.
    • [^] # Re: SIGTROLL

      Posté par  . Évalué à 4.

      > OpenBSD n'a aucun besoin d'être comparé à quoi que ce soit.

      Page d'acceuil :
      http://www.openbsd.org/
      Only two remote holes in the default install, in more than 10 years!

      Bon, ben, on ne dira pas que c'est mieux que Windows puisqu'il ne faut pas comparer.

      Au fait, pourquoi le "Only" si ça ne se compare à rien ?

      > OpenBSD n'a aucun besoin d'être comparé à quoi que ce soit.

      Lui peut-être pas, mais les autres ont peut-être envis. Si la comparaison est faite sur les mêmes bases, c'est très bien. Refuser les comparaison c'est car :
      - soit on a la trouille
      - soit on veut cacher quelque chose

      Est-ce OpenBSD va faire comme Orable pour interdire les comparaisons ?

      Si la comparaison n'est pas possible, comme ici, ben on ne compare pas. C'est ce qui est dit dans le journal.
      Si quelqu'un veut dépouiller les données de Red Hat (ou n'importe) et le données d'OpenBSD (ou n'importe) pour faire une comparaison sur des bases justes, je l'y invite. Choisir un OS ne doit pas se faire seulement sur des slogans.

      > Range ton troll à deux francs CFA,

      Le "Only two remote holes in the default install, in more than 10 years!" c'est aussi un troll. Et en première page...

      http://www.redhatmagazine.com/2007/04/18/risk-report-two-yea(...)
      Various reports have tried to compare operating systems from different vendors, some by comparing numbers of vulnerabilities, others looking at days of risk, some recent ones even written by the competing vendor themselves. You can pretty much get whatever results you like from such comparisons by simply carefully choosing the initial conditions or ignoring differences in disclosure and policies. I think it’s far more useful to let RHEL4 users get a good picture of the risk they faced, and with our raw data available they can tailor it to their environment and way they use RHEL4. For example we treat an issue as severity important if an local user can cause a machine to crash, but if you are in an environment where that isn’t an issue (maybe you don’t have untrusted local users or maybe crashes are not a big deal) then you can rerun our stats accordingly.
      • [^] # Re: SIGTROLL

        Posté par  . Évalué à 7.

        Pour une fois je suis d'accord avec toi ;-)

        La notion de faille de securite chez OpenBSD se reduit comme peau de chagrin avec le temps.
        Ca commence avec les failles locales. puis remote (je vous invite a utiliser archive.org).
        Ici commenca la lente descente aux enfers de la communication:
        - Les failles ne sont que pour l'installation "par defaut" (OpenSSH sans separation de privileges, apache (chunked encoding qui sous OpenBSD uniquement permettait de chopper un acces root))
        - La notion de "failles de stabilite" qui permet de ne pas comptabiliser les sources de DoS en failles de secu (headers IPv6)
        - Et depuis peu les failles "probablement tres peu exploitable" (PNRG)
        • [^] # Re: SIGTROLL

          Posté par  . Évalué à 1.

          En même temps un DoS ne compromet pas la sécurité du système. Ce genre d'attaque se contente de rendre un service non disponible (en faisant planter un processus par exemple) donc il n'a pas lieu de les déclarer en temps que faille de sécurité. Ce sont bel et bien des failles de fiabilité.

          Et puis pourquoi ne pas être fier de n'avoir eu qu'un faible nombre de faille de sécurité dans l'installation par défaut, même si cela réduit ce que l'on peut faire avec. C'est bien connu, moins il y de services qui tournent, moins il y a de sources potentielles de failles mais si ça ne les élimines pas toutes. Au moins, je sais que l'installation par défaut et une bonne base pour construire quelque chose par dessus.

          Chaque faille d'OpenBSD est annoncée et un patch est toujours disponible en même temps pour corriger le problème (et ce pour tout le système, pas uniquement pour l'installation par défaut !). Je ne sais pas ce qu'il vous faut mais moi ça me convient parfaitement pour tenir à jour mes machines.

          À ce jour il y a eu 8 correctifs pour OpenBSD 4.2 : 3 de sécurité, 4 de fiabilité et 1 pour corriger un problème de boot sur CD sur certaines machines. Je ne vois vraiment pas ce qui vous chagrine dans ce décompte.
          • [^] # Re: SIGTROLL

            Posté par  . Évalué à 1.

            un DoS peut compromettre la sécurité d'une architecture (fait un DoS sur un serveur de syslog, et ensuite vas dire "mais non c'est qu'un problème de fiabilité" au sysadmin). Il est donc aussi tout a fait normal de les déclarer en tant que faille de sécurité.


            Chaque faille d'OpenBSD est annoncée et un patch est toujours disponible en même temps pour corriger le problème
            Ils codent plus vite que leur ombres : avant même que la faille est annoncé, ils avaient déjà un patch de prévu....
            • [^] # Re: SIGTROLL

              Posté par  . Évalué à 2.

              Ils codent plus vite que leur ombres : avant même que la faille est annoncé, ils avaient déjà un patch de prévu....

              Les patches pour les failles sécurités sont souvent triviaux et même publiés par les sites ou organismes qui mettent en lumière le problème.
              • [^] # Re: SIGTROLL

                Posté par  . Évalué à 2.

                On doit pas avoir les mêmes problèmes de sécurité...
                D'ailleur c'est tellement le cas ce que tu raconte que normalement, lors de la publication d'une faille, on contacte jamais les principaux partenaires avant, le temps qu'ils trouvent le patch, et qu'ils soient prêt à le diffuser.

                Suffit juste de sortir la faille, et dans les 20 minutes (c'est tellement trivial) tout es prêt à être diffuser.

                C'est beau la sécurité chez toi quand même. Tu peux me donner une partie de ton stock de poudre verte ?
                • [^] # Re: SIGTROLL

                  Posté par  . Évalué à 2.

                  Désolé, je me suis mal exprimé :

                  Trouver puis corriger une faille de sécurité (ou un bug en général) est évidemment un travail non trivial. La procédure va impliquer des échanges comme tu l'indiques avec les principaux partenaires. Mais quand tu en es au point d'être sûr d'avoir une faille de sécurité (tu as circonci le domaine d'application, etc), le correctif n'est souvent pas loin.

                  L'annonce d'une faille et de son patch sont la plupart du temps simultanés (tu ironisait la dessus et c'est à ça que je répondais à l'origine). Il parait que c'est le cas pour de sombre histoire de politique de sécurité qui sont le sujet ici de beaux trolls a propos de la sécurité par l'obscurité :)

                  Pour infos, les patches pour la version 4.2 de OpenBSD sont là : http://openbsd.org/errata42.html

                  La plupart sont 'triviaux' et ne font que quelques lignes, sauf un qui en fait dans les 600 (je ne les ai pas vraiment étudiés non plus).

                  Maintenant on peut éventuellement revenir au sujet du journal qui concerne RedHat, et pas OpenBSD :)
                  • [^] # Re: SIGTROLL

                    Posté par  . Évalué à 4.

                    Pour bosser dans le domaine, je peux te dire que c'est loin d'etre vrai.

                    C'est facile de voir un code et se dire "ben il suffit de changer xyz".
                    Le probleme, c'est qu'apres:
                    - il faut verifier(revue de code/design) que ton changement il ne casse rien, et ca prend du temps dans certains cas.
                    - il faut chercher et trouver les variantes de la faille originale, ca demande de faires des revues de code/design, du fuzzing, ... ca prend du temps (parce que si tu sors ton patch sans corriger les variantes, t'es bon pour des 0-days a la pelle)
                    - il faut tester le patch, ca prend du temps, enormement de temps
                  • [^] # Re: SIGTROLL

                    Posté par  . Évalué à 2.

                    > L'annonce d'une faille et de son patch sont la plupart du temps simultanés

                    La publication de la faille avec le patch est souvent simultanné. Mais la découverte de la faille peut être bien antérieur à la publication.
                    Même s'il n'y a pas publication, tu cours un risque. Si un gentil a découvert la faille, un méchant cracker peut aussi le faire.
                    • [^] # Re: SIGTROLL

                      Posté par  . Évalué à 3.

                      Je n'ai pas dis le contraire, et j'espère que tout le monde en est bien conscient. Ce n'est pas parce qu'on utilise un système d'exploitation qui se veut « sécurisé » que l'on est à l'abri.

                      Et ce serait un doux euphémisme d'avoir une méthode ultime pour mesurer la sécurité de n'importe quel système et ce avec précision.
                  • [^] # Re: SIGTROLL

                    Posté par  . Évalué à 2.

                    C'est pas par ce qu'un patch ne fait que quelques lignes qu'il est trivial à écrire. Et si l'annonce de la faille et le patch se font de facon simultanés la plupars du temps, c'est par ce que la personne qui a decouvert la faille attend qu'elle soit corrigée avant de la rendre publique.
            • [^] # Re: SIGTROLL

              Posté par  . Évalué à -2.

              un DoS peut compromettre la sécurité d'une architecture (fait un DoS sur un serveur de syslog, et ensuite vas dire "mais non c'est qu'un problème de fiabilité" au sysadmin). Il est donc aussi tout a fait normal de les déclarer en tant que faille de sécurité
              Oui et heureusement, cela ne s'est pas encore produit. Dans les failles de fiabilité ou de stabilité, on retrouve les kernel panics, les freezes, les boucles infinies, certaines bases de données corrompues, ...
              Il faut bien évidement noter que ces failles n'entrainent pas de failles de sécurité !
              • [^] # Re: SIGTROLL

                Posté par  . Évalué à 1.

                pour toi la sécurité c'est juste "compromettre un systême" , et jamais, au grand jamais, la possibilité de crasher un système (avec l'ensemble des services qui tourne dessus) ne te pose un quelconque problême...

                On dois pas avoir la même notion de sécu alors.

                Qu'un attaquant ne puisse pas désactiver/crasher mes serveur fait partie de l'équipe SECU et non pas Quality , désolé !
                (Quality travaille en amont du déploiement normalement)
                • [^] # Re: SIGTROLL

                  Posté par  . Évalué à 2.

                  Exactement, si mon serveur plante, ce n'est pas un problème de sécurité, c'est un problème de stabilité.
                  • [^] # Re: SIGTROLL

                    Posté par  . Évalué à 2.

                    Stabilite et securite ne sont pas 2 entites totalement separees et distinctes.

                    Tu peux avoir un probleme qui est un probleme de stabilite ET un probleme de securite.
                  • [^] # Re: SIGTROLL

                    Posté par  . Évalué à 1.

                    et si c'est un serveur qui gere les atterissages dans un aeroport ou l'aiguillage des trains? La disponibilite d'un systeme et des applications dessus peuvent etre aussi des problemes de securite!
                    • [^] # Re: SIGTROLL

                      Posté par  . Évalué à 2.

                      Je ne dis pas qu'il ne faut pas prendre en compte le contexte dans lequel le serveur tourne, au contraire.

                      Mais si on reste au niveau du système d'exploitation en lui-même, sans se préoccuper de ce qui tourne dessus et autour, un plantage reste un plantage. Tout ce qui importe est de corriger ce problème pour que ce plantage ne se reproduise plus. Les développeurs écrivent des correctifs de stabilité et de fiabilité pour ça !

                      Ce n'est pas aux développeurs du système d'exploitation de se préoccuper si éventuellement peut-être dans un certain contexte cela poserait un problème de sécurité.


                      Après si toi, administrateur des machines qui contrôle l'aéroport, tu n'es pas capable de voir que si une machine qui n'est pas stable ni fiable cela va compromettre la sécurité des passagers (dans cet environnement bien particulier), je souhaite ne jamais monter dans un de tes avions.

                      Mais moi, si mon pauvre serveur plante, ben il ne se passera rien de dramatique : aucune donnée n'aura été volée, aucun programme malveillant n'aura été exécuté, la sécurité de mes autres machines n'aura pas été compromise non plus, ... et il n'y aura pas mort d'homme. Bref vraiment pas une faille de sécurité pour moi.
                      • [^] # Re: SIGTROLL

                        Posté par  . Évalué à 1.

                        Mais moi, si mon pauvre serveur plante, ben il ne se passera rien de dramatique

                        Va dire ça aux entreprises ! une interruption de service peux couter, selon le cas, très, trèèèèèès chère.
                        • [^] # Re: SIGTROLL

                          Posté par  . Évalué à 1.

                          Oui, je n'en doute pas. C'était pour illustrer l'importance du contexte dans lequel le système se trouve.
                  • [^] # Re: SIGTROLL

                    Posté par  . Évalué à 1.

                    > Exactement, si mon serveur plante, ce n'est pas un problème de sécurité, c'est un problème de stabilité.

                    C'est un problème de sécurité !
                    Si ton serveur plante car un autre a décidé de le faire planter, c'est un problème de sécurité.
                    S'il plante car tu joues à tuxracer, ce n'est pas un problème de sécurité.
                    • [^] # Re: SIGTROLL

                      Posté par  . Évalué à 1.

                      C'est bien le problème de stabilité _qui implique_ ton problème de sécurité. Donc à la base cela reste un problème de stabilité.

                      Ton serveur aurait très bien pu planter dans les même condition avec un client plein de bonne volonté, mais ayant juste un comportement bogué ou légèrement différent des autres.
                      • [^] # Re: SIGTROLL

                        Posté par  . Évalué à 1.

                        > Donc à la base cela reste un problème de stabilité.

                        Dans la sécurité il y a un attaquant et un attaqué. Tout ce qui permet à l'attaquant de nuire à l'attaqué est une faille de sécurité. Les DoS en font parti.
                        Notons bien que l'attaquant n'est pas "sous-contrôle". Ce n'est pas un utilisateur de confience.
                        Que la faille soit exploitable (par l'attaquand et non l'utilisateur) ou non en fonction du problème est une autre histoire.
                        Mais si la faille est exploitable, ta seule solution est de corriger le problème.

                        Pour la fiabilité, c'est une autre histoire. Il n'y a pas d'attaquant, il n'y a pas de personne qui veut nuire et qui n'est pas "sous-contrôle", etc.
                        Si l'admin en jouant à tuxracer fait planter le serveur, il y a un correctif simple à ce problème => engueuler l'admin pour qu'il ne recommence pas. En général ça marche très bien. Par contre, engueuler les attaquants pour qu'il ne recommence pas, marche très très très mal.

                        Si la sécurité n'est pas de tes préocupations, ben classe les DoS comme un problème de fiabilité. Mais tu vas vite voir qu'il y a une différence entre un admin qui n'est pas content de ne plus pourvoir jouer à tuxracer durant ses heures perdues et des clients qui ne peuvent plus utiliser un service que tu leur as vendu ou ton serveur qui enregistre les payements qui ne marche plus. D'un le premier cas, t'as un mécontent, dans le second ton business est en jeu. T'es dans l'insécurité. Que cette insécurité vienne d'un système peu solide est accessoire. C'est avant un problème de sécurité.

                        > Ton serveur aurait très bien pu planter dans les même condition avec un client plein de bonne volonté, mais ayant juste un comportement bogué ou légèrement différent des autres.

                        La sécurité ce n'est pas l'art de chercher des arguments pour croire qu'on est en sécurité. C'est souvent l'inverse. Si un client plein de bonne volonté l'a fait, un cracker peut le faire. C'est donc un problème de sécurité. La sécurité doit se faire si possible avant que tout soit cassé. Pas après. Il ne faut pas attendre que tout soit cassé pour agir.
                        • [^] # Re: SIGTROLL

                          Posté par  . Évalué à 1.

                          La sécurité et la fiabilité sont deux de mes préoccupations principales pour un serveur. Dans certain contexte, qu'elles soient intimement liées est un fait. Mais cela ne veut pas dire que je ne peut pas pas en faire clairement la distinction.

                          Juger de sa sécurité personnelle (dans la vraie vie) n'est pas la même chose que de juger la sécurité d'un système d'exploitation en lui-même.
                          • [^] # Re: SIGTROLL

                            Posté par  . Évalué à 1.

                            > Juger de sa sécurité personnelle (dans la vraie vie) n'est pas la même chose que de juger la sécurité d'un système d'exploitation en lui-même.

                            Mouais. Mais j'espère que l'OS que tu utilises traite les DoS avec le zèle que mérite une problème de sécurité et pas comme un banal problème de fiabilité.

                            - Pourquoi ce bug n'est pas corrité alors qui me fait perdre des milliers d'€ par jour !
                            - Patron, c'est un problème de fiabilité, pas de sécurité. Ce n'est pas prioritaire.
                            - Pardon ?
                            - Ben oui, la sécurité n'est pas compromise.
                            - OK, ok... Donc qu'un cracker puisse planter ma bécane est normal ? Donc qu'un cracker puisse décider que mon système passe 95 % de son temps en train de booter est normal ? Ce n'est pas un abus de mes ressources ?
                            - Vous avez tout compris patron.
                            - Je vais peindre les vitres de ta bagnole et t'expliquer que c'est un problème de visibilité et pas de sécurité. En passant, vous n'êtes plus responsable des serveurs.
                            • [^] # Re: SIGTROLL

                              Posté par  . Évalué à 1.

                              Qui a dit que les problèmes de fiabilité peuvent être traité avec zèle et que l'on peut les prendre à la légère ? surement pas moi, ni toi d'ailleurs. On est bien d'accord là dessus.
                              • [^] # Re: SIGTROLL

                                Posté par  . Évalué à 0.

                                Si tu branches une clée USB et que ça plante ta bécane, c'est un problème de fiabilité. Un cracker ne va pas venir brancher la clée USB à ta place.
                                Le branchement d'une clée USB n'est pas un DoS (sauf pour celui qui veut utiliser la clée USB pourrait-on dire). Un freeze noyau à cause de tuxracer n'est pas un DoS. Pour ces cas, c'est une demande de prestation qui n'aboutit pas. Une demande qui n'est pas "plante la bécane".

                                Tous les vrais DoS sont des problèmes de sécurité. Ce n'est pas une prestation demander par l'utilisateur qu'on n'arrive pas à fournir (par exemple lire une clée USB), c'est une prestation qui n'est pas disponible à des utilisations car un autre utilisateur à fait planter la bécane. Et pourquoi il l'a fait ? Pas pour lire une clée USB ou jouer à tuxracer, mais juste pour planter la bécance et priver tous les utilisateurs d'un service.

                                En passant, il y a des DoS qui ne sont pas des problèmes de fiabilité. Ça ne plante rien, ça ralentit (terriblement) le service.

                                > Qui a dit que les problèmes de fiabilité peuvent être traité avec zèle et que l'on peut les prendre à la légère ?

                                Le problème est de dire qu'un DoS est un problème de fiabilité et non de sécurité. Un DoS est toujours un problème de sécurité et parfois aussi un problème de fiabilité.

                                Si un serveur plante toutes les 10 minutes de façon alléatoire (sans le concours d'un cracker), c'est seulement un problème de fiabilité. Un problème grave assurément et ça concerne le service QA. Mais ce n'est pas un problème de sécurité. La sécurité c'est se protéger des crackers, pas d'un matos qui déconne ou d'un mauvais logiciels. Si le logiciel est mauvais, ben on ne le met pas en production.
                    • [^] # Re: SIGTROLL

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

                      je croyais, de mon point de vu de user, que le terme (très) générique de "sécurité" désignait généralement à la fois la sécurité d' accès ET la sécurité de fonctionnement.

                      Ca doit être le défaut des termes génériquement vulgarisés.
          • [^] # Re: SIGTROLL

            Posté par  . Évalué à 1.

            > En même temps un DoS ne compromet pas la sécurité du système. Ce genre d'attaque se contente de rendre un service non disponible (en faisant planter un processus par exemple) donc il n'a pas lieu de les déclarer en temps que faille de sécurité. Ce sont bel et bien des failles de fiabilité.

            Non. Si tu as un "ennemi", il peut être très content de faire des DoS sur tes bécanes. Et toi tu ne seras pas content. Si tes bécanes sont nécessaires à ton business, tu es dans l'insécurité.
            Un DoS est un problème de sécurité.

            > Chaque faille d'OpenBSD est annoncée et un patch est toujours disponible en même temps pour corriger le problème

            Voir le rapport du journal...
            Ceci est très probablement faux. Où c'est un abus de l'utilisation du secret. Lorsqu'une faille est découverte mais toujours pas public, Red Hat (et beaucoup d'acteurs) applique le secret[*]. Un secret relatif, puisque les personnes concernées sont informées (mainteneurs, etc). Après diffusion de la correction, il n'y a plus de secret. Si Red Hat ou le mainteneur upstream a mis 10 jours pour corriger la faille, ben ils vont dire qu'ils ont mis 10 jours et pas 0 même si personne ne peut le vérifier.


            [*] Le bugzilla de Red Hat propose de mettre les bugs de sécurité en confidentiel. Chaqu'un est libre de refuser. L'aspect confidentiel est de la responsabilité de celui qui soumet le bug et Red Hat le respecte (ce qui est normal).
          • [^] # Re: SIGTROLL

            Posté par  . Évalué à 1.

            Et puis pourquoi ne pas être fier de n'avoir eu qu'un faible nombre de faille de sécurité dans l'installation par défaut, même si cela réduit ce que l'on peut faire avec. C'est bien connu, moins il y de services qui tournent, moins il y a de sources potentielles de failles mais si ça ne les élimines pas toutes. Au moins, je sais que l'installation par défaut et une bonne base pour construire quelque chose par dessus.

            Encore heureux qu'il n'y ait pas beaucoup de failles exploitables à distance et permettant de passer root dans l'install par defaut, puisqu'il n'y a quasiment aucun service qui tourne. Tu prends l'equivalent sur beaucoup de distributions linux, et je pense que tu as à peu près les memes chiffres.

            Chaque faille d'OpenBSD est annoncée et un patch est toujours disponible en même temps pour corriger le problème (et ce pour tout le système, pas uniquement pour l'installation par défaut !). Je ne sais pas ce qu'il vous faut mais moi ça me convient parfaitement pour tenir à jour mes machines.

            Qu'est ce que tu appelles exactement "tout le système" ?
            • [^] # Re: SIGTROLL

              Posté par  . Évalué à 1.

              Qu'est ce que tu appelles exactement "tout le système" ?

              Tout ce qui a dans le dépôt CVS du projet : en gros tout /usr/src (le noyau, l'userland, openssh, httpd (apache), sendmail...) et xenocara (xorg).
              • [^] # Re: SIGTROLL

                Posté par  . Évalué à 2.

                Ca c'est le systeme de base.

Suivre le flux des commentaires

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