Tout en dépendant de la faille (y'en a des bien tordues) à partir du moment ou l'endroit est identifiée et la cause comprise le code n'est qu'une question d'heures ou de jours.
> Ca semble logique, si tu tombes sur une faille dans le kernel linux, t envoies ton rapport à Microsoft.
Tu fais expres de faire le boulet ? Tout les vendeurs ont un security@domaine qui est une adresse privée et seuls les interessées (la team securité) recoivent l'information ca permet justement d'éviter que trop d'info ne se balandent pour indiquer qu'une faille existe avant que ca soit patché. Il me semble que linux ne dispose pas d'une telle adresse; si pour signaler un probleme de sécu tu dois le poster sur lkml ca me parait un peu contradictoire avec ce que tu avances.
> On analyse pas les raisons, on analyse le code justement. Ce code fait crasher linux.
"Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits" tu appels ca analyser le code ?!? C'est une intepretation des faits d'autruit. Quand le mec a balance le code sur le bugzilla de gcc il n'avait pas forcement compris l'impact a partir de ce moment c'était trop tard. La lecon de l'exploit dans la VM linux n'a pas marqué les esprits apparement. Les "pirates" ne sont pas tous des guignols du dimanche qui vont sur 1337.c0m pour chopper les exploits, y'en a aussi qui codent pour des projets libres, qui suivent les changelogs, les bugzilla, qui lisent du code.
> Non, il a juste rendu publique une faille de sécurité, ainsi que le programme rendant vulnérable la quasi totalité du parc informatique LINUX x86.
C'est un fait.
> Ton indifférence est compréhensible, car tu n'as pas de connaissances suffisantes en matière de développement ou d'administration système .
Mouhaha je l'a bookmark celle la :-)
Ce n'est pas de l'indifference, c'est qu'a partir d'un moment tu es conscient que les failles n'existent pas qu'a partir du moment ou ./ en a parlé. Des failles noyaux y'en a une trippotée non divulgée ca en a toujours été ainsi. Tu as le choix entre un truc inconnu possedé par peu de personnes ou quelques chose de très répendu qui sera vite corrigé. Si ton entreprise est sensible je prefere de tres loin la seconde solution. Si tu es qu'une societe X ou Y alors effectivement il y a plus de risques de casse dans le second cas. C'est une faille locale, a partir du moment ou tu laisses quelqu'un faire un exec() il doit y avoir un minimum de confiance et de controle. L'utilisateur doit savoir qu'il sera puni en cas d'abus les autres ne devraient pas acceder a la machine.
"Ensuite une dizaine de petits malins de votre boite se sont empressés de faire sauter les serveurs ."
Faute grave, licenciement, tribunal (godfrain/LSI). Tes employes peuvent foutre le feux aux locaux, ou voler le matos informatique. Ils ne le font pas soit pas ce que ce ne sont pas des crétins soit par ce qu'ils en connaissent les conséquences. En informatique il en va de même.
Ce n'est ni la premiere ni la derniere faille, il y en aura toujours certaines publiques, certaines privees les conséquences variant selon la sensibilité de ce à quoi sert le parc. Si tu n'arrives pas a dormir avec cette idée et cette gestion du risque change de métier. Je te signal qu'au moins 3 codes pour l'exploit de la VM ont été publiés très rapidement et qu'au moins un était fonctionel presque tel quel...
[^] # Re: Bravo linux ...
Posté par ckyl . En réponse au journal faille dans les linux 2.4.2x et 2.6.x. Évalué à 4.
Réalité mon pauvre.
>T'es sérieux ?
Tout en dépendant de la faille (y'en a des bien tordues) à partir du moment ou l'endroit est identifiée et la cause comprise le code n'est qu'une question d'heures ou de jours.
> Ca semble logique, si tu tombes sur une faille dans le kernel linux, t envoies ton rapport à Microsoft.
Tu fais expres de faire le boulet ? Tout les vendeurs ont un security@domaine qui est une adresse privée et seuls les interessées (la team securité) recoivent l'information ca permet justement d'éviter que trop d'info ne se balandent pour indiquer qu'une faille existe avant que ca soit patché. Il me semble que linux ne dispose pas d'une telle adresse; si pour signaler un probleme de sécu tu dois le poster sur lkml ca me parait un peu contradictoire avec ce que tu avances.
> On analyse pas les raisons, on analyse le code justement. Ce code fait crasher linux.
"Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits" tu appels ca analyser le code ?!? C'est une intepretation des faits d'autruit. Quand le mec a balance le code sur le bugzilla de gcc il n'avait pas forcement compris l'impact a partir de ce moment c'était trop tard. La lecon de l'exploit dans la VM linux n'a pas marqué les esprits apparement. Les "pirates" ne sont pas tous des guignols du dimanche qui vont sur 1337.c0m pour chopper les exploits, y'en a aussi qui codent pour des projets libres, qui suivent les changelogs, les bugzilla, qui lisent du code.
> Non, il a juste rendu publique une faille de sécurité, ainsi que le programme rendant vulnérable la quasi totalité du parc informatique LINUX x86.
C'est un fait.
> Ton indifférence est compréhensible, car tu n'as pas de connaissances suffisantes en matière de développement ou d'administration système .
Mouhaha je l'a bookmark celle la :-)
Ce n'est pas de l'indifference, c'est qu'a partir d'un moment tu es conscient que les failles n'existent pas qu'a partir du moment ou ./ en a parlé. Des failles noyaux y'en a une trippotée non divulgée ca en a toujours été ainsi. Tu as le choix entre un truc inconnu possedé par peu de personnes ou quelques chose de très répendu qui sera vite corrigé. Si ton entreprise est sensible je prefere de tres loin la seconde solution. Si tu es qu'une societe X ou Y alors effectivement il y a plus de risques de casse dans le second cas. C'est une faille locale, a partir du moment ou tu laisses quelqu'un faire un exec() il doit y avoir un minimum de confiance et de controle. L'utilisateur doit savoir qu'il sera puni en cas d'abus les autres ne devraient pas acceder a la machine.
"Ensuite une dizaine de petits malins de votre boite se sont empressés de faire sauter les serveurs ."
Faute grave, licenciement, tribunal (godfrain/LSI). Tes employes peuvent foutre le feux aux locaux, ou voler le matos informatique. Ils ne le font pas soit pas ce que ce ne sont pas des crétins soit par ce qu'ils en connaissent les conséquences. En informatique il en va de même.
Ce n'est ni la premiere ni la derniere faille, il y en aura toujours certaines publiques, certaines privees les conséquences variant selon la sensibilité de ce à quoi sert le parc. Si tu n'arrives pas a dormir avec cette idée et cette gestion du risque change de métier. Je te signal qu'au moins 3 codes pour l'exploit de la VM ont été publiés très rapidement et qu'au moins un était fonctionel presque tel quel...