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.
Journal Évaluation des risques de RHEL 4
27
fév.
2008
# SIGTROLL
Posté par gaston . Évalué à -3.
Range ton troll à deux francs CFA, OpenBSD n'a aucun besoin d'être comparé à quoi que ce soit.
[^] # Re: SIGTROLL
Posté par IsNotGood . Évalué à 4.
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 nullisimo . Évalué à 7.
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 ErrTu . É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.
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 briaeros007 . Évalué à 1.
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 Hank Lords . Évalué à 2.
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 briaeros007 . Évalué à 2.
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 Hank Lords . Évalué à 2.
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 pasBill pasGates . Évalué à 4.
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 IsNotGood . Évalué à 2.
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 ErrTu . Évalué à 3.
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 Anonyme . Évalué à 2.
[^] # Re: SIGTROLL
Posté par ErrTu . Évalué à -2.
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 briaeros007 . Évalué à 1.
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 ErrTu . Évalué à 2.
[^] # Re: SIGTROLL
Posté par pasBill pasGates . Évalué à 2.
Tu peux avoir un probleme qui est un probleme de stabilite ET un probleme de securite.
[^] # Re: SIGTROLL
Posté par abramov_MS . Évalué à 1.
[^] # Re: SIGTROLL
Posté par ErrTu . Évalué à 2.
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 gnu_castor . Évalué à 1.
Va dire ça aux entreprises ! une interruption de service peux couter, selon le cas, très, trèèèèèès chère.
[^] # Re: SIGTROLL
Posté par ErrTu . Évalué à 1.
[^] # Re: SIGTROLL
Posté par IsNotGood . Évalué à 1.
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 ErrTu . Évalué à 1.
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 IsNotGood . Évalué à 1.
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 ErrTu . É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.
[^] # Re: SIGTROLL
Posté par IsNotGood . Évalué à 1.
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 ErrTu . Évalué à 1.
[^] # Re: SIGTROLL
Posté par IsNotGood . Évalué à 0.
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 bubar🦥 (Mastodon) . Évalué à 3.
Ca doit être le défaut des termes génériquement vulgarisés.
[^] # Re: SIGTROLL
Posté par IsNotGood . Évalué à 1.
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 Anonyme . Évalué à 1.
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 ErrTu . Évalué à 1.
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 Anonyme . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.