pasBill pasGates a écrit 16280 commentaires

Tu as encore une fois compris de travers.

La justice a decide que "Windows" n'etait pas une marque deposee de MS, ca n'interdit pas a MS d'appeler son soft Windows, ca lui interdit juste de le revendiquer l'exclusivite.

La stack du temps de 95 avait ete achetee a une boite, et cette boite s'etait basee sur BSD, mais ensuite MS a reecrit sa propre stack pour resoudre les nombreux problemes de perf et autres qui se trouvaient dans cette vieille stack.

Pour info, ce fichier n'est absolument pas utilise par la stack tcp/ip, ce fichier est utilise par la resolution de noms(DNS client), la stack tcp/ip elle ne traite rien d'autre que des addresses IP. J'ai pris cet exemple pour te faire comprendre la logique dans laquelle des softs sont ecrits, ils peuvent sembler similaires de l'exterieur, et c'est normal car c'est le but, mais sont ecrit de maniere totalement differente de l'interieur.

Et je ne vois pas quels softs iraient lire ce genre de fichier, même sous les unix classiques personnes ne va lire /etc/hosts, c'est juste à la résolution de noms que le système va d'abord là avant de taper sur le DNS. Et c'est le boulot de l'OS, donc à la limite peu importe comment il fait. Ok pour les APIs communes, mais je ne voyais pas le fichier hosts comme une API...

Un fichier c'est une API, si tu regardes une fonction exportee, c'est rien d'autre qu'une description du format des donnees a envoyer, un fichier et son format c'est la meme chose. Tu peux prendre un /etc/hosts sur Unix et le transposer sur Windows tres simplement, voila un des avantages.

Pour patcher tcpip.sys le worm doit etre admin, si il est utilisateur il ira nulle part.

Et puis le worm, s'il n'est pas ****, il se charge dans le kernel nt de maniere a excuté son code en ring 0 .

Il peut, mais ca limite de nouveau le type de worm, ils peuvent pas etre executes par un user simple, ils doivent etre assez complexe pour pouvoir patcher un kernel, etc... bref ca rehausse la difficulte. Le but n'est pas d'empecher totalement les worms, on sait que c'est pas possible, le but est de rendre la chose plus difficile.

Ils se sont plantes, le patch en question fixe un probleme relatif au loopback (127.x.x.x), rien a voir avec la limitation en SYN_SENT

Comme tu as pu le constaté, j'ai facilement donné une période avec des failles critiques connues non-corrigées, donc avec des machines XP crackables instantanément. Comme par hasard, nous sommes dans une de ces périodes.

Mais c'est genial ! T'as trouve qu'un jour, il y a eu une faille et donc que XP etait exploitable, si tu veux je te listes un tas de cas ou Linux, Solaris, ... etaient expoitable aussi.

Si tu n'es pas capable de donner une période sans exploit maintenant, tu ne respectes pas les utilsiateurs de win qui sont inquiets par la facilité avec laquelle j'ai trouvé une période exploitable.

Une periode ? Tres simple, ton lien : http://secunia.com/product/22/(...)

Entre le 13 octobre 2004 et le 25 decembre 2004, aucune faille importante n'a ete recensee dans XP, entre le 8 fevrier et le 14 avril non plus, ... Il suffit de regarder les dates de release des vulnerabilites.

Je te l'ai montre, tu racontes n'importe quoi, et tu as meme donne le baton toi-meme pour te faire battre.

On a _volontairement_ bloque cette cle de registre, le but de cette feature est d'empecher les worms genre blaster/sasser/... d'infecter un reseau de maniere rapide, si une cle de registre permet de passer outre, t'imagines bien que le worm va changer cette cle de registre lui-meme et elle n'aura alors plus aucun sens.

Un bon cours d'histoire informatique te ferais du bien je crois.

a) AIX n'a rien du tout a voir avec OS/2, mais alors rien du tout
b) OS/2 a ete developpe en commun par Microsoft et IBM, et a un moment ils ont forke
c) NT n'a rien a voir avec OS/2 non plus, NT etait prevu pour etre le kernel sur lequel l'OS OS/2 serait base, mais quand MS et IBM se sont separes, MS a implemente Win32 par dessus NT (et une personality OS/2 basique pour etre compatible), alors que IBM est parti creer son propre kernel pour baser son OS/2 dessus

C'est un fichier qui est choisi avec le meme nom histoire que les gens s'y retrouvent plus facilement, de la meme maniere que Winsock implemente les API berkeley afin que les softs soient facilement portables, ca veut pas dire que le code sous jacent est le meme.

Je te paries 1 million qu'il n'y a aucune cle de registre pour contourner la chose. Mais a ta place je parierai pas, on est en train de parler du composant sur lequel je bosses tous les jours :+)

Apres lecture de ta page, mon petit doigt me dit que la raison de la lenteur se trouve dans la fenetre de congestion: http://www.faqs.org/rfcs/rfc2001.html(...)
Tu devrais lire la RFC et voir si ca s'applique a ton cas.

On reconnait bien là, la politique légendaire de Microsoft en matière de sécurité, puisque cette limitation serait contournable via une improbable valeur dans une clé de la fumeuse base de registre.

C'est pas configurable dans la registry, c'est en dur dans la stack.

Il ne faut pas se fier aux rumeurs, la stack est 100% MS

T'aurais une capture reseau de la chose(filtree pour ne contenir que ce qui est necessaire si possible...) histoire que je jette un coup d'oeil ? Ma preference va a Netmon, mais si c'est du Ethereal je peux vivre avec.

Désolé mais je peux pas tout faire.
Mais puisque toi tu aimes les archives, cite moi une période où il n'y avait pas de failles critiques non corrigées !

J'ai rien a te citer moi, c'est a toi de prouver tes dires, et depuis le debut du thread tu te defiles.

Comme par hasard, et alors que tu prétendais le contraire, on est dans une période où les failles crtiques connues sont pas corrigées.

Arretes de sortir des conneries et donne un lien sur ces failles.

C'est dingue une mauvaise foi pareille, soit tu prouves tes dires soit tu te tais, c'est pas si complique a comprendre pourtant que tu es sense avoir un minimum d'arguments valables pour supporter tes affirmations non ?

A quel endroit j'ai dit que toutes étaient dues au threads ?

Ou ai-je parle de toutes les failles ?

Désolé que tu comprennes pas, mais tous ceux qui fréquentent régulièrement cette page Secunia ont compris, eux. Tous les jours où on visite cette page, on peut y constater que chaque jour on peut rentrer par effraction dans un systeme XP. Point.

Tu continues a te defiler, files moi ces liens ou arretes de sortir des conneries !

Je n'ai pas d'archive du site Secunia. Et je ne vais pas en chercher une pour tes beaux yeux. Mais tous ceux qui visitent cette page régulièrement savent qu'il n'y a quasiment jamais de jour sans que XP soit crackable à l'aide d'une faille critique.

Ah parce que t'as besoin des archives pour me montrer ce qu'il se passe aujourd'hui ? Le lien que tu as donne ( http://secunia.com/product/22/(...) ) recense les failles jusqu'a 2002, t'as besoin de plus que ca ? Tu te fous de moi ?

Aies un minimum de bonne foi et reconnais que tu as raconte n'importe quoi.

Tu continues a te defiler mon cher :

- Tu pretends que les failles sont dues aux threads, et hop, rien pour justifier
- Tu pretends qu'il y a plein de failles non corrigees dans Windows, et hop, rien pour justifier

Serieux, t'en as pas marre de sortir des conneries et te defiler a chaque fois ?

Maintenant, soit tu me justifies ce que tu as sorti, c'est a dire :

- Les failles sont dues au systeme de threads
- Les failles critiques ne sont pas corrigees

Ou alors svp tu te tais et tu arretes de sortir connerie sur connerie.

Donnes moi le lien sur une faille "highly critical" qui date de plus de 2 semaines et qu'on n'a pas corrige. Apres, peut-etre que je te prendrais au serieux.

T'as pas tout a fait compris il semble, quand tu lances "Demarrer en tant que", il te demande le mot de passe de l'utilisateur sous lequel tu veux lancer le soft.

Et il y en a combien qui sont critiques et qui sont restees non patchees ? Ah ben oui, aucune.

Faudrait penser a faire un peu plus que de la lecture et mettre les mains dans le cambouis mon cher si tu veux que je te prennes au serieux, il n'y a jamais rien pour soutenir tes dires.

Et combien il y en a qui sont "highly critical" et qui ne sont pas corrigees ?

Mais c'est quand meme dingue comme on a devie du sujet principal sur un sujet qui n'a _absolument rien_ a voir car pour je ne sais quelle raison bizarre et que tu n'as toujours pas expliquee et prouvee tu as dit que les failles de securite dans Windows etaient causees par les threads.

Ca serait franchement bien que tu mettes quelques arguments valables dans tes dires, parce que quand je te lis j'ai l'impression que tu ne fais qu'une chose : tu lis la theorie et tu extrapoles sans jamais avoir touche a la pratique.

Alors si j'ai bien compris a faille qu'utilise sasser etait "inoffensive" ?

La faille qu'a utilise Sasser avait ete corrigee avant que le virus existe, ca n'a rien a voir donc.
Si tu regardes la liste des soi-disant failles non corrigees sur le site, tu verras qu'elles sont extremement limitees et/ou demandent des conditions tres particulieres pour etre reproduisibles, bref ne sont pas exploitables.

Je n'en sais rien sur la fait que des threads introduisent plus de failles (meme si je me permet d'emettre quelques reserves dessus) mais dire que windows est un havre de securite je trouve ca un peu ose quand meme.

Je ne dis pas que c'est un havre de securite, par contre je dis que les failles qui posent un risque on les corrige, les autres vu qu'elles ne posent pas de risque bien evidemment sont traitees differement selon les cas.

Remarque, ca aurait ete bien pour l'espece humaine que 90% des texans soient homos, ca aurait peut-etre permis d'eviter Bush...

Ok, je -->[]

Tu apprendras aussi a analyser ce que tu lis avant d'en tirer des conclusions hatives, et alors tu remarqueras que toutes ces soi-disantes failles reportees sont inoffensives dans l'enorme majorite(celles qu'on ne corrige pas), et en train d'etre corrigees pour les autres.

Et a part ca, tu t'es defile encore une fois, donne moi donc ces exemples montrant que les failles dans Windows sont dues aux threads.

Mais comme d'habitude tu vas eviter de repondre je suppose et detourner le sujet sur autre chose.

Justement, beaucoup d'utilisateurs de windows aimeraient bien que l'architeture multithread de win déconne moins souvent, et avec moins de failles de sécurité publiques non corrigées depuis trop longtemps. Pourquoi ne sont-elles pas corrigées rapidement ?

Tu peux arreter de raconter des conneries STP ?
1) Cites moi des failles publiques non corrigees dans Windows(je parles pas d'IE qui est un browser)
2) Cites moi donc des failles dans l'archi multi-thread de Windows

Ce que tu racontes la c'est 100% conneries, du vent, rien d'autre et soit tu le sais, soit tu vis sur la lune mon cher.

Parce que le moindre changement peut perturber la dynamique des threads, cf l'article que l'on commente, et fait apparaitre de nouveaux bugs. C'est ça l'enfer des threads.

Tu ne sais absolument pas de quoi tu parles, et c'est vraiment gonflant.