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

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é…

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

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 ?

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

Je fais quand même la mise à jour.

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…

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).

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

(lol)

le mien es OK oufff!!

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