18 Commentaire(s)

1. 

   Unknownn 

   Et ouais, je suis déjà immunisé ^^ Un peu en retard Korben je vois
   10 secondes suffisent lorsqu’on a un accès shell pour obtenir les droits Root. Donc pensez-y. Puis il n’est pas difficile de mettre à jour son kernel

   Posté le 12 février 2008 à 22:51:23

2. 

   PyR 

   Ptainn!!

   le mien es OK oufff!!

   Posté le 12 février 2008 à 23:22:46

3. 

   admin 

   @Unknownn : Scuze, j’ai taffé toute la journée :o)

   Posté le 12 février 2008 à 23:27:03

4. 

   Pti-seb 

   “Sur lâ??excellent site Tux-planet” : je suis flaté !

   Posté le 12 février 2008 à 23:50:13

5. 

   Angelarme 

   Pas difficile… mais perso je ne sais pas comment faire. :p

   (lol)

   Posté le 13 février 2008 à 00:26:38

6. 

   Tom 

   OMG c’était donc ça ce nouveau noyau dans les mises à jour d’ubuntu tout à l’heure. Pffuiii, on a eu chaud. (ou pas)

   Posté le 13 février 2008 à 03:18:00

7. 

   Piwaï 

   3 jours de retard, c’est inadmissible ! haha.. vouaip, par ailleurs moi j’attend toujours la mise à jour automatique d’ubuntu qui va corriger ça.. Ho bah tiens ! A peine je tape ça dans le champ texte que voila l’icône “Mises à jour logicielles disponibles” qui s’affiche… avec la mise à jour des linux-headers. Suis-je en train de devenir fou, ou est-ce que mon Ubuntu me comprend ? (ou peut-être que c’est simplement que la première chose que je lis en allumant mon PC, c’est korben…)

   Posté le 13 février 2008 à 08:20:18

8. 

   Florian 

   Hop faille du kernel rebouchée ^^

   Posté le 13 février 2008 à 11:34:31

9. 

   GroMeZ 

   �a aurait été bien de mettre un lien vers le patch ou les bug report

   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=712a30e63c8066ed84385b12edbfb804f49cbc44
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953

   Corrigé dans le gentoo-sources-2.6.24-r2

   Posté le 13 février 2008 à 12:58:43

10. 

    Vorenus 

    C’est amusant comme il y a quelques jours pas mal de gens se moquaient des BSOD de Las Vegas (alors que les ordis derrière tournaient vraisemblablement sous Windows 2000 d’après les screens alors que c’est un OS qui a 8 ans, et que c’était certainement un problème de drivers et non de l’OS en soit…) et que quand Linux a un gros trou de sécurité, on trouve encore le moyen de mettre un beau logo “Linux rocks” et que tout le monde tient des propos très modérés sur les commentaires (je ne parle pas d’ici, mais d’autres sites).

    Je ne dis pas que Windows “c’est mieux que Linux”, mais juste que les systèmes sont vulnérables tôt ou tard et plus ou moins gravement…
    Il ne viendrait pas à l’esprit de beaucoup de gens tournant sous Windows de se moquer de cette faille… pourquoi la réciprocité ne serait pas vraie ?

    Je ne parle pas forcément des gens d’ici, mais certains linuxiens passent leur temps à basher Windows et c’est fatiguant… surtout quand on sait que la grande majorité des écrans bleus sous NT provient des drivers et non de l’OS lui-même… (les drivers tournent dans le kernel, et ils n’ont donc pas le droit à l’erreur, car non-isolés).

    Posté le 13 février 2008 à 14:54:24

11. 

    Tom 

    Je suis d’accords avec toi dans le fond, Vorenus, mais ce que l’on peut noter c’est la rapidité de réaction à cette faille: à peine connue qu’elle était comblée! Ca n’exclut pas l’existence d’autres failles, mais c’est déjà plus rassurant que des failles Windows connues et non traitées pendant des semaines…

    Posté le 13 février 2008 à 14:58:32

12. 

    Vorenus 

    Tom,

    Je suis d’accord avec toi aussi, mais je mitigerais en disant deux choses :

    Premier point, c’est la communauté IT dans son ensemble qui a réclamé que Microsoft soit “moins réactif” sur la sortie des patchs.
    Aussi étonnant que cela puisse être, cela posait des problèmes dans les départements informatiques des sociétés car les patchs sortaient “au compte goûte” et sans calendrier ou planning.
    C’est donc ainsi qu’est né le fameux “Patch Tuesday”, le second mardi du mois, car cela permettait aux admins de mieux planifier les mises à jour et d’intégrer tout cela à leurs projets, plutôt que de tout laisser tomber pour vite patcher en panique. Une ou deux semaines avant, MS envoit un mail sur une ML et met à jour son site pour dire combien des patchs vont être sortis et quels produits seront concernés.

    Deuxième point, et c’est un sujet qui ferait encore plus débat, c’est la politique de “vulnerability disclosure”.
    Cette faille de Linux a apparemment été en full vulnerability disclosure : les détails et proof of concepts ont été balancés au public avant que les gens aient eu la moindre chance de patcher.
    Effectivement, dans ce contexte, il vaut mieux être hyper-réactif, et dans une telle situation, Microsoft a effectivement sûrement tendance à plus prendre son temps que les gens qui bossent sur Linux.

    La plupart du temps, les chercheurs de vulnérabilités contactent d’abord Microsoft, sans donner les détails de la vulnérabilité au public, ce qui permet à Microsoft de régler le problème sans trop de pression et en testant la compatibilité à fond (ce qui n’empêche pas certains problèmes, évidemment).
    Le fait que les vulnérabilités ne soient pas publiées permet d’éviter que tous les hackers se jettent sur la faille et cherchent à l’exploiter avant que le patch ne soit sorti.
    Même si on ne donne pas de proof of concept, mais qu’on dit juste “Il y a une vulnérabilité sur le chargement du format .ICO”, on donne une joli piste aux hackers (car il sait déjà que la faille se trouve donc très probablement dans l’API LoadImage ou une fonction appellée par cette dernière, par exemple).

    Beaucoup de gens sont d’accords pour dire que la sécurité par l’obscurité n’est pas un excellent principe, mais quand on cherche à l’aveuglette en utilisant des fuzzers ou en analysant le code au pif, on a quand même moins de probabilités de trouver quelque chose que quand on te montre où il y a un problème.

    Je me méfie quand même quand on parle de réactivité extrème, car un patch sorti super vite ne peut pas être testé à fond, surtout sur la palette aussi vaste et variée de machines sur lesquelles sont installées Windows.
    Cela explique un peu, en plus du Patch Tuesday qui a été voulu par les utilisateurs et les admins, les lenteurs de Microsoft a sortir les patchs.
    Plusieurs fois, des chercheurs indépendants ont sorti des patchs officieux, et quasiment à chaque fois, le patch ne marchait pas correctement sur certaines machines et configurations. Qu’on s’appelle Windows ou Linux, tester prend du temps, mais c’est loin d’être superflu…

    Posté le 13 février 2008 à 15:14:47

13. 

    Diti 

    Testé sur Ubuntu en 2.6.22-14 (vulnérable, donc) : ça fait planter le système 10 bonnes minutes (!), puis aucun accès root.

    Je fais quand même la mise à jour.

    Posté le 13 février 2008 à 15:32:53

14. 

    Steph' 

    @ Vorenus,
    http://www.theinquirer.fr/2008/02/12/le_crime_organise_paye_pour_que_des_vulnerabilites_ne_soient_pas_publiees.html#
    et en V.O. :
    http://news.smh.com.au/web-security-report-says-known-vulnerabilities-fall-because-criminals-pay-to-hide-them/20080212-1rrs.html#

    Peut-être peux-tu nous parler de la certification des drivers par Microsoft, puisqu’ils n’ont pas droit à l’erreur : pourquoi des pilotes officiels plantent-ils (”les drivers tournent dans le kernel, et ils nâ??ont donc pas le droit à lâ??erreur, car non-isolés”) ? En quoi consiste cette certification ?

    @ Korben : continue, c’est toujours un plaisir de te lire
    Bonne journée

    Posté le 13 février 2008 à 15:37:06

15. 

    Vorenus 

    Steph,

    Concernant tes liens, je suis au courant et j’irais même plus loin : le crime organisé paie des experts en sécurité (un peu underground quand même) pour les trouver et/ou les utiliser ensuite pour leur compte !
    J’avais lu une interview d’un gars qui avait plusieurs contrats avec des sociétés de spyware pour permettre l’injection d’ads/spam-bots ou de keyloggers ainsi que d’autres boîtes pour effectuer de l’espionage industriel.

    Ca a toujours existé et ça existera toujours (et pas que dans l’informatique) : je ne vois pas trop où tu veux en venir ni ce que tu essaies de réfuter ? Il est évident qu’il existe des tas de vulnérabilités qui sont exploitées aujourd’hui et dont personne ne connaît l’existence et qui ne figurent pas dans les bases de données de Secunia ou autre…
    Si c’est un argument en faveur de la full-disclosure, ça n’en est pas un car si personne d’autre que le criminel a detecté la vulnérabilité, comment pourrait-être disclosée par quelqu’un d’autre que lui, sachant qu’il n’en a pas l’intention ?

    Maintenant concernant les drivers, déjà il ne s’agit pas de pilotes officiels (ce n’est pas Microsoft qui les a programmés), ils sont juste signés “WHQL” ce qui signifie qu’ils ont passé une batterie de tests dans les labos de MS : http://en.wikipedia.org/wiki/WHQL

    Avant tout, je cite ma source concernant ce que j’ai affirmé dans mon poste précédent concernant la cause des BSODs.
    http://book.itzero.com/read/microsoft/0507/Microsoft.Press.Microsoft.Windows.Internals.Fourth.Edition.Dec.2004.internal.eBook-DDU_html/0735619174/ch14lev1sec1.html

    70% des BSODS proviendraient de drivers defectueux (évidemment, vu que c’est un livre édité chez MS Press, des mauvaises langues vont dire que les chiffres ont été trafiqués…….)

    Maintenant pour les raisons pourquoi cela planterait :
    - Parce qu’il s’agit de drivers non signés ? (pas tous ont la certification WHQL, surtout en l’an 2000 dont je parlais à propos des screens) où ce programme venait d’être mis en place.

    - Parce que le programme WHQL de Microsoft n’est au bout du compte, qu’une batteries de tests, aussi developpé soit-il ne pourra jamais trouver tous les bugs et qu’il est difficile pour un programme externe de tester le “code coverage” à 100% d’un driver, surtout au niveau binaire et non du code source (certains bugs comme les race conditions ne se voient que lorsque le driver tourne).
    Si de tels programmes existaient, on aurait aucun bug ni vulnérabilité.

    - Parce que certains problèmes sont liés à des problèmes de hardware (barette mémoire corrompue ou autre) et donc se produiraient certainement aussi sous Linux, etc ?

    Si tout le monde lançait un analyze -v avec WinDBG sur le crash dump généré par Windows lors de l’écran bleu, ils auraient de belles surprises, entre autres, de voir le nom du driver incriminé.

    Encore une fois, je ne sais pas trop ce que tu cherches à démontrer si ce n’est que le programme WHQL n’est pas parfait, mais personne ne prétend qu’il l’est, puisqu’aucun programme de vérification syntaxique ou comportementale de code n’est parfait, et encore plus quand il doit interagir avec du hardware dont le programme n’a aucun moyen de faire tourner 100% du code du driver.

    Cela signifie juste que le driver a passé avec succès les tests de MS sur une vaste gamme de machines de tests et qu’il respecte la documentation et les appels aux fonctions du kernel et qu’il est donc supposément plus fiable qu’un driver developpé pour un matos bas de gamme ou no-name par des gens sous-payés… (souvent quand on achète du matos d’entrée de gamme, les drivers ne sont pas signés…)
    Maintenant, ça me semblerait un peu fort de blamer MS s’il s’agit un bug dans un driver programmé par un tiers.
    Si un conducteur (driver) d’un véhicule se plante parce qu’il est bourré ou s’endort au volant, blame-t-on le constructeur ?

    Maintenant, je ne suis pas un spécialiste de Linux, mais j’imagine qu’un driver vaseux (comme tout ce qui tourne en mode privilégié/ring 0) doit bien faire crasher la machine, non ?

    Posté le 13 février 2008 à 16:54:37

16. 

    1ace 

    par prudence j’ai jetté un oeil au code source, et en première ligne je vois “jessica_biel_naked_in_my_bed.c”… bon, 6 ligne plus loin on voit “Linux vmsplice Local Root Exploit”, ça va, c’était juste une mauvaise blague…

    Pour Vorenus, j’ai pas lu ton dernier post (trop gros morceau ^^) mais j’ai remarqué le dernier paragraphe… La principale différence entre Windows et Linux sur ce point est que sous Linux, les développeurs recherchent pas juste l’argent, donc s’ils sortent des machins qui foirent dans tous les sens ils peuvent pas juste dire “Attendez, on va sortir un patch, dans quelques mois…”, donc ils ne publient pas des drivers ou autres programmes s’ils ne sont pas stables, ou alors il le font mais en le précisant

    Posté le 13 février 2008 à 19:35:30

17. 

    Vorenus 

    @1ace,

    Bah, si je peux me permettre, c’est dommage de répondre sans lire les réponses complètes car ça m’aurait évité d’avoir à réecire la même chose plus ou moins en condensé. ;-p

    C’est à dire que les BSODs proviennent en majorité des drivers et que Microsoft endosse une bonne partie des responsabilitiés auprès des Linuxiens qui ont beau jeu de critiquer l’OS du voisin, parfois sans vraiment le connaître.
    Je ne connais pas trop Linux alors je ne m’aventurerais pas à parler de son Kernel par exemple.

    Par exemple, les BSODs de Windows 9x étaient en grande partie de la responsabilité de Microsoft car le système était relativement mal isolé en termes de protection d’espace de chaque processus : c’était clairement un mauvais design, mais ce n’est plus le cas aujourd’hui.
    Perso, je me demande toujours pourquoi le modèle NT n’a pas été adopté dès le départ…

    Si on veut critiquer Microsoft, on peut le faire et ce n’est pas ce qui manque…
    Je hais Windows Vista (qui renie la cohérence de l’interface utilisateur auxquels des utilisateurs sont habitués depuis des années et qui étaient le point fort de l’OS et ne tournerait correctement pas sur 75% de mon parc), l’activation, le WGA, et je ne suis pas un pirate : juste un admin qui en a marre de perdre du temps lors des déploiements avec ces méthodes de protection débiles qui n’empêche pas le piratage au bout du compte.

    Si on veut rechercher un programme Windows relativement bien buggé, le Shell est vraiment pas mal dans le genre et “gèle” de temps en temps, particulièrement quand on utilise des network shares, par exemple… alors pourquoi ressortir ces vieilles histoires de BSOD et de sécurité ? (Microsoft a fait un travail assez énorme sur ce point depuis plusieurs années, notamment avec la SDL (un système de detection de vulnérabilités au niveau du code source : http://blogs.msdn.com/michael_howard/ ), qui malheureusement est un système interne.

    Franchement, si les Linuxiens veulent critiquer Windows, qu’ils mettent à jour leurs listes de critique car les BSODs et la sécurité, ça date (il y en a, mais désormais c’est dans les mêmes proportions qu’ailleurs)…

    Puis, en ce qui concerne les drivers, Microsoft n’y peut vraiment rien à part améliorer son programme WHQL : si les développeurs de drivers tiers sortent un truc à la hâte, ils n’y sont franchement pas pour grand chose.

    C’est toujours le problème que les gens ont avec Microsoft : le SP1 de Vista est prêt mais pas diffusé au public pour l’instant afin que certains constructeurs de matériels mettent à jour leurs drivers… alors les gens râlent, mais ils oublient qu’ils râleraient encore plus si MS n’attendait pas et qu’ils y avait des problèmes dont MS les aurait pourtant prevenus…

    MS a ses torts, mais tout ce qui tourne et plante sous Windows n’est pas de leur responsabilité…

    Posté le 13 février 2008 à 20:38:12

18. 

    Diti 

    Merci d’avoir publié l’exploit, ça m’a permis de convaincre l’administrateur du serveur noobulous.fr (j’ai un accès SSH dessus) pour régler la faille.

    Le noob, il préférait laisser les gens jouer à la sécurité de son serveur !

    Posté le 15 février 2008 à 19:23:24

1 Trackback(s)

1. 15 février 2008 à 14:52:52: de Microsoft se lance dans la conception de vers (virus) | Korben's Blog

Lacher un com'