pasBill pasGates a écrit 16057 commentaires

C'est vrai que ma reponse est idiote, dire qu'il ne faut pas installer des applications qui ont des failles est vraiment stupide.

Promis je ne recommencerais plus.

Bien, va faire la meme chose avec une distrib Linux:

Bonjour monsieur, j'aimerais une distribution Linux avec un serveur de mail qui ne contient pas de buffer overflow, pas de memory leaks, et qui ne leak pas de donnees confidentielles.

Le vendeur de la FNAC va tomber dans les pommes aussi, et si tu gueules au support que sendmail c'est de la merde, ils te riront au nez aussi(ou ils le changeront si ils sont un minimum intelligents).

C'est le meme probleme.

Et si tu veux un anti-virus correct, essayes eTrust de Computer Associates

La personne hostile met une page web avec un contenu qui profite d'une faille dans le browser de popol pour creer un remote shell depuis la machine de popol qui se connecte a l'exterieur.

Resultat, c'est une connection sortante, le firewall laisse passer, et la personne hostile a acces total a la machine de popol.

Le truc est que 99% des gens ne font pas d'applications graphiques qui ont besoin de tourner en tant que root, donc ils n'ont meme pas a se poser la question, ils n'ont pas ce probleme.

Les seuls cas sont les processus du type service/daemon car ceux-ci ont quelque fois besoin de tourner en root, et quand tu ecris ce genre de soft tu es sense avoir un minimum de connaissance sur l'OS, et tu es sense savoir que le service lui-meme ne doit pas afficher la GUI, mais ce doit etre une appli separee qui tourne dans le contexte de l'utilisateur, et qui communique avec le service a travers COM ou autre.

Bref, ce truc touche 1% des programmeurs, la gigantesque majorite des programmeurs font des softs qui ne tournent pas en root.

Toi tu trouves ca effarant car tu es habitue a une autre approche, mais il faut voir que Windows et Linux(enfin X Window) ne fonctionnent pas du tout de la meme maniere au niveau GUI, ce sont 2 architectures differentes et non comparables.

Il suffit donc d'avoir UNE application graphique qui tourne en root (sous Windows la plupart des applis ont une interface graphique) et qui soit épisodiquement dans cette file pour pouvoir passer root.

La méthode que décrit l'article s'appuie sur un anti-virus, mais on peut imaginer des tas d'autres applis.


C'est bien, t'as compris le principe.

Maintenant comprend la suite: de base dans l'OS, AUCUN process root n'a de GUI sur le desktop de l'user, et les recommendations de MS precisent tres clairement qu'il ne faut pas le faire pour des raisons de securite.

Sous Windows, les services(ceux de base) qui tournent en root n'affichent pas eux meme une GUI, elle est separee du service, la GUI tourne avec les droits de l'user et communique a travers COM avec le service, c'est ce que recommende MS et quand tu fais les choses correctement tout se passe bien.

Alors oui, tu peux imaginer plein d'applis, ca ne change rien au fait que la faille serait dans l'appli, pas dans l'OS.

De meme, je peux imaginer plein de daemons qui acceptent des commandes depuis le reseau et qui tournent en root, ce sont aussi des failles enormes, c'est pas la faute de l'OS pour autant.

C'est simple, tu installes un anti-virus qui est concu de maniere correcte, c'est a dire le service tourne en root, et la GUI est separee du service, tourne avec les droits de l'users et communique a travers COM ou autres, et il y en a des anti-virus concus correctement.

Mais moi non seulement je l'ai lu, mais je l'ai compris.

C'est quelque chose de connu depuis DES ANNEES, ce gars n'a rien invente, il n'a fait que mettre en pratique.

Mais si tu y tiens vraiment, expliques moi en quoi c'est une faille de l'OS, tu arriveras peut-etre a eclairer ma lanterne.

Mais je n'ai jamais dit que toutes les applis avaient besoin d'etre root...

Quelque unes en ont besoin, et si un jour tu en installes une qui en a besoin, et qu'elle a un trou de securite, ben tu te retrouves dans la meme situation qu'un service tournant en root sous Windows qui affiche une fenetre sur le desktop d'un user.

Dans les 2 cas c'est la faute du service/daemon, pas de l'OS.

Quand au fait qu'il serait vite "mis hors-la-loi", ca c'est ton imagination qui te le fait dire. wu_ftpd, sendmail et bind sont hyper repandus depuis des annees.

Finalement, je le repetes encore une fois... Il faut que root intervienne pour que cette attaque puisse avoir lieu, car par defaut dans l'OS, aucun service n'affiche de fenetre sur le desktop d'un user.
La seule possibilite est que l'administrateur installe un service qui est troue, donc oui il faut intervention de l'administrateur.
Si tu ne me crois pas, va installer un Win2000 et essaye, tu verras par toi-meme.

Super ta poesie, mais dans le cas present il n'y a aucune difference entre Unix et Windows, dans les 2 cas si tu suis pas les recommendations pour les services tournant en root, tu finis avec une autoroute.

Je te le repetes encore une fois, tu n'as rien compris au probleme.

Un utilisateur avec des droits restreints ne peut devenir root QUE SI L'ADMIN A FAIT UNE BOURDE.

Cette bourde etant d'installer un service tournant avec les droits admins qui fait apparaitre lui-meme(donc en tant que root) une fenetre sur le desktop de l'utilisateur plutot qu'utiliser une GUI qui a des droits restreints.

La SEULE possibilite pour etre vulnerable a cela est donc que l'admin a fait une bourde en installant un daemon avec permissions root qui est troue, comme sur Unix.

Prends un Windows 2000 de base avec les services livres avec l'OS, essaye cette attaque, elle ne marchera pas, car les services livres avec l'OS sont codes selon les recommendations et n'affichent pas de fenetre directement sur le desktop de l'utilisateur.

Si tu veux utiliser cette attaque il faut que l'admin ait fait une connerie avant(installer un service troue).

Tout comme sous Unix, si l'admin installe un daemon tournant en root et qui accepte des commandes de n'importe qui ca revient au meme, c'est pas la faute de l'OS, mais du programmeur du daemon et de l'admin qui a installe le daemon.

desktop et winstation sont tellement bugges qu'ils sont a la base de Terminal Services et que le fast-user switching de XP n'existerait pas sans eux.

Sinon, il n'existe pas de protection sur les queues de message car l'architecture de la GUI le veut ainsi.

Un choix a ete fait qui est que toutes les fenetres sur le desktop peuvent agir entre elles, ca implique en contre-partie qu'il n'y ait pas de fenetre "root" sur le desktop de l'utilisateur, c'est un choix qui facilite bcp de choses, et qui en contre-partie demande un petit effort pour ceux qui creent des services.

Parce que si le systeme devait empecher les developpeurs de faire toutes les conneries possibles, ca ferait un systeme qui tient sur 4 DVD, qui a besoin de 16 P4 2Ghz en parrallelle et 4Go de RAM pour tourner.

Donc il y a des choix qui se font.

Quand une app root ouvre un socket, aucun mecanisme dans l'OS ne verifie qu'elle n'accepte pas des commandes de n'importe qui, aucun OS ne verifie que l'app n'a pas de buffer overflow, que ce soit Unix ou Windows. L'OS assume que si tu fais tourner un soft en root, tu sais ce que tu fais. Ce probleme est identique ici.

Si tu es root et tu installes un daemon pourri qui est ouvert a tout le monde, t'as beau etre sur Windows ou Unix, tu te retrouves dans la merde.

Le "probleme" ici present c'est exactement ca, car pour pouvoir entrer dans le systeme par une de ces portes, il faut que l'administrateur ait installe ce soft pourrave, un user simple ne peut pas installer de service, la seule chose qui change est le type de vulnerabilite dans l'application.

C'est surtout que tu n'as rien compris au probleme.

Ce n'est pas un bug de conception de Windows mais un probleme pour les developpeurs de services(=daemons) qui ne respectent pas les recommandations de Microsoft, a savoir: pas de fenetre sur le desktop d'un user pour un service tournant avec des droits autres que celui de l'user. C'est specifie depuis tres longtemps dans les recommandations, et les idiots qui ne respectent pas cela mettent en danger le systeme, de la meme maniere que sous Unix tu mets en danger le systeme si tu as un daemon qui tourne en root et qui accepte les commandes de n'importe quel utilisateur.
Le bug dans l'exemple du gars sur Slashdot, c'est dans l'anti-virus qui affiche une fenetre sur le desktop de l'user alors qu'il tourne comme service avec acces root ce qui est contraire aux recommandations de MS, le bug n'est pas dans l'OS.

Bref, va relire la chose.

Si j'en crois http://news.com.com/2100-1040-957077.html?tag=fd_lede(...) , il faut croire que non.

Les gens mettent du temps a passer au SP1 de XP car le systeme est stable et ils ne voient pas de raison d'updater leur systeme.

Tu m'expliques ou est-ce que tu vois une partie "espionnage" dans Palladium ?

Il ne s'agit de rien d'autre que d'un systeme qui verifie la signature de documents/fichiers/executables/.... avant de les lancer en gros, je vois pas ce qu'il espionne.

C'est pas exactement ca mais c'est tres proche(en gros certains modeles de Toyota sont uniquement vendus avec du Michelin)

Il sera peut-etre licencie, peut-etre pas, la question est:

est-ce que la faute en incombe automatiquement a Michelin ou est-ce que la decision pourrait avoir ete prise par Toyota independamment de Michelin ?

Dans le cas present, on balance la faute sur MS, son monopole, etc... alors que RIEN ne montre qu'il s'est fait jeter a cause de pressions de MS.

Ca ne repond pas a ma question.

Lorsque une societe licencie un employe qui critique les produits qu'elle distribue, est-ce que la faute incombe automatiquement au fabricant du produit ou il se pourrait que la decision ait ete prise par la societe sans pression du fabricant ?

Ben il reste encore a voir pourquoi Perens s'est fait taper sur les doigts, et je ne vois rien qui indique que cela soit du a des pressions de MS.

Si c'etait du a des pressions de MS, ca pourrait se comprendre(et encore, faut voir quelles pressions), mais jusqu'a maintenant rien n'indique que MS y a mis son grain de sel, cela pourrait tout a fait etre HP qui a decide seul que Perens allait trop loin(critiques sur les produits vendus par HP, histoire de DecCSS,...), sans que cela ait un quelconque rapport avec les liens entre HP et MS, donc il faudrait eviter de tirer la charrue avant les boeufs.

Dis moi, si un employe de Toyota se fait rappeler a l'ordre ou licencier apres avoir critique les pneus mis en standard sur les Toyota, c'est la faute du constructeur de pneus ?

J'aime bien comme tu me fais dire ce que je n'ai pas dit...

On sait bien que MS est la cause de tous les maux de la planete, tu nous l'as assez repete.

N'empeche que je connais peu de societes qui aiment que leurs employes critiquent les produits qu'elles vendent, maintenant si tu veux mettre ca sur le dos de MS, libre a toi, moi je preferes utiliser mon cerveau et garder les yeux ouverts.

Décidement style, discernement, tact et élégance feront toujours défaut de l'autre coté de l'Atlantique.

Pour ce qui est du discernement, du tact et de l'elegance c'est sur que c'est pas en suivant ton exemple que je vais progresser...

Je vois pas le rapport entre le monopole de MS et cette histoire.

Ces societes vendent du MS et lui dit que c'est de la merde, desole mais je connais peu de societes qui acceptent de laisser leur employes dire que les produits qu'ils vendent sont de la merde.

Il aurait pu faire de meme avec les processeurs Intel et il se serait fait rappeler a l'ordre aussi, il aurait pu bosser chez Toyota et dire que les Corolla sont de la merde, il se serait fait taper sur les doigts aussi, pourtant Toyota n'est pas un monopole.

Si t'as que 2-3 machines a administrer c'est sur que la GUI suffit amplement, mais quand tu te retrouves avec un parc de 400 machines, ben la la GUI c'est tres limite, et un script, ben que ce soit 2 ou 400 machines, le script il s'en fout.
C'est la l'avantage du script sur la GUI.

C'est que si il n'y a que 2 machines a gerer, ecrire un script prend plus de temps que faire le truc par la GUI, mais pour les parcs de machines c'est l'inverse.

Les noms que tu cites sont des langages de développement dont certains sont carrément à compiler. Est-ce à dire qu'il faut écrire une appli pour administrer?

Certains sont a compiler, je ne fais que dire qu'il est possible d'utiliser un tas de langages, tu veux ecrire un script, t'utilises VBScript, si pour une raison X tu veux utiliser un langage compile, va faire du C++ ou autre.

VBScript, COM, group policies et WMI c'est:
1) Tres bien connu des admin systeme competents
2) tres documente, cf. Google: http://www.google.ch/search?q=WMI+COM+domain&ie=UTF-8&oe=UT(...) ou MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wm(...)

Donc plutot que critiquer MS pour son cote soi-disant non-documente, je proposes que tu te documentes sur la chose, car c'est documente, connu et ca existe depuis un petit moment maintenant.

Euh non, je suis encore en vacances

Il n'y a pas besoin de Terminal Services ou VNC pour administrer un Win2k ou autre a distance.

Pour ca tu as WMI et les Group policies.
Tout ce petit monde est accessible a travers VBScript, C, C++,... vu qu'ils ont des interfaces COM

Les gens qui utilisent la GUI pour administrer les serveurs sont ceux qui ne connaissent pas le systeme, les autres se font pas chier, ecrivent un script et appliquent le changement a toutes les machines en un retour de chariot.