Cette faille n'affecte pas tous les systèmes UNIX mais quelques déclinaisons. La distribution Linux Mandrake serait affectée (jusqu'à la version 8.0) ainsi que les systèmes Solaris 2.6 (Intel et Sparc) et Solaris 7 Sparc.
En revanche, RedHat 7.2 ne serait pas vulnérable...
Cette faille permet une connexion en root sur le système attaqué.
Avant que la faille ne soit corrigée, il est recommandé de désactiver les connexions à distance et de filtrer le port 177.
# BugReport Scheduling
Posté par Wi][ish . Évalué à -9.
Le monde ne tourne plus rond.
[^] # Re: BugReport Scheduling
Posté par Wawet76 (site web personnel) . Évalué à 10.
[^] # Re: BugReport Scheduling
Posté par anonyme512 . Évalué à 10.
voir http://www.nikosoft.net/niouzes/article.php?sid=26(...) qui cite notamment http://www.procheckup.com/security_info/vuln_pr0208.html(...)
on le voit, rien de bien difficile à "patcher", juste un "#" à mettre au bon endroit.
il y a aussi un (court) fil de discussion au sujet de xdm/kdm et de pourquoi la Mandrake 8.1 fonctionne différement de la 8.0 (mais aurait pu quand même avoir le bug)
[^] # Re: BugReport Scheduling
Posté par fantomaxe . Évalué à 10.
Ben non, sinon faut retourner chez microsoft ;-) surtout que le moyen de corriger (provisoirement) la faille est décrite dans l'article... en attendant
le service packun patch correctif.[^] # Re: BugReport Scheduling
Posté par Wi][ish . Évalué à 4.
Ok, donc le jour où je trouve THE Buffer Overflow qui permet de lancer un remote shell sur
n'importe quels Linux ou *BSD, je l'annonce en très gros sur LinuxFr. Yaura pas de patch, mais c'est pas grave puisque une règle DENY ALL permet de contrer la faille.
Non, je reste persuadé que lorsqu'on trouve une faille de cette ampleur, la première chose à faire et d'écrire le correctif et de l'envoyer à l'auteur, ou alors de prévenir discretement les développeur avant de mêtre le bordel sur le net. Et là, on parle d'OpenSource pas de LP.
C'est pas tout de bloquer le 177 (UDP j'ai cru lire), mais si ce XDMCP est indispensable au sein d'une société, on ne peu pas le bloquer comme ça pour le traffic intérieur. Donc dire que l'on peut filtrer le port "ok", mais ça ne resoud pas plus de problèmes que cette news n'en crée vu que 80% des attaques se font justement de l'intérieur...
Voilà, je ne comprend toujours pas.
[^] # Re: BugReport Scheduling
Posté par Aza . Évalué à 4.
>n'importe quels Linux ou *BSD, je l'annonce en >très gros sur LinuxFr.
Oui et même sur slashdot, comme ca tu sauras sur que le patch sera disponible en quelques heures.
>Yaura pas de patch, mais >c'est pas grave >puisque une règle DENY ALL >permet de contrer la >faille.
Ca permettra d'attendre le patch qui ne tardera pas a arriver.Envoyer la faille aux developpeurs et attendre ca ne fonctionne pas toujours, déja parceque les développeurs sont réduits et peuvent etre ailleurs (en vacances, malade, en cours..) qu'ils peuvent avoir autre chose a foutre (puisque tu n'as prevenu personne d'autre, le patch peut attendre...) et aussi parceque ce n'est pas parceque toi tu as trouvé la faille que personne d'autres de plus mal intentionné ne l'a trouvé. On a vu ca récement avec un bug dans php je crois : la faille etait connue dans les milieux "underground" mais personne ne s'etait presse pour prevenir les developpeurs.
Gueuler une bonne grosse faille sur le net c'est le meilleur moyen de forcer les developpeurs a se bouger...
[^] # Re: BugReport Scheduling
Posté par syntaxerror . Évalué à 0.
par défaut. Et ça ne donne pas accès au système, mais tout juste d'essayer
des attaques du genre "brute force". De toute façon, installer un chooser
sans vérifier la config ni restreindre la liste des systèmes autorisés,
fait aimer les risques.
[^] # Re: BugReport Scheduling
Posté par Olivier M. . Évalué à 3.
[^] # Re: BugReport Scheduling
Posté par Anonyme . Évalué à 10.
[^] # Re: BugReport Scheduling
Posté par the_freeman . Évalué à 10.
# faut dire...
Posté par Anonyme . Évalué à 10.
Parce qu'a priori, ça ne concerne pas tant de monde que cela...
Logiquement, quand GDM est installé, c'est par défaut désinstallé.
[^] # Re: faut dire...
Posté par ufoot (site web personnel) . Évalué à 3.
Dans tous les cas, le fait meme d'installer xdm sur un serveur est pour le moins original.
Linux (UNIX en general) a justement l'avantage d'offrir la possibilite de ne pas installer de couche graphique. Autant en profiter...
[^] # Re: faut dire...
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
[^] # Re: faut dire...
Posté par PLuG . Évalué à 7.
Ils n'ont pas encore capté que
1/ c'est dangereux
2/ c'est inutile (on peut installer un client smit graphique et exporter le DISPLAY sans avoir le serveur X sur le serveur !!)
donc X11 lourd, gourmand, inutile et buggé jusqu'a etre dangereux tourne sur beaucoup de serveurs en DMZ ... ARG!!
(alors de la a laisser XDMCP en plus ...)
[^] # Re: faut dire...
Posté par syntaxerror . Évalué à -4.
# Ben alors .... mais franchement ou est le problème ?
Posté par rycks . Évalué à 10.
je ne maitrise pas beaucoup l'anglais mais bon j'ai bien lu et relus ... je ne vois pas du tout ou est la "faille importante" ...
Tout au plus on donne la liste des logins dans une bête boite (g|k)dm oui ça aide les méchants à faire du cassage de mots de passe en force ...
"II. Impact
An attacker may gain sensitive information about users permitted to login to the system. This may aid in brute-force attacks against the system."
Ben oui ... normal mais c'est pas une faille importante des systèmes unix ... reveillez-vous ! c'est la même chose que de donner la liste des utilisateurs, ok ça affaiblit la sécurité globale mais je ne trouve pas du tout que ça soit une "faille"!
Et puis, pour avoir installé des serveurs de terminaux graphiques, la liste des images/logins qui s'affiche c'est un des premiers trucs qu'on vire dès qu'on a plus de 200 utilisateurs, imaginez la tronche de la boite de connexion avec 200 photos ... injouable !
Allez, je retourne à la pêche aux moules !
Éric
eric.linuxfr@sud-ouest.org
[^] # Re: Ben alors .... mais franchement ou est le problème ?
Posté par Gniarf . Évalué à 4.
(config par défaut souvent constatée ou de commodité, par exemple Mandrake 7.2)
[^] # Re: Ben alors .... mais franchement ou est le problème ?
Posté par Sativas . Évalué à 7.
Pouvoir redemarrer le systeme comme cela, c'est adapté a une machine qui n'est utilisée que par une personne a la fois, pas pour un serveur de connexions distantes.
[^] # Re: Ben alors .... mais franchement ou est le problème ?
Posté par Robert Chéramy . Évalué à 8.
Si tu penses à la fenêtre à laquelle je pense, le menu système (redémarer, arrêter, etc) n'est disponible qu'à l'utilisateur local et c'est désactivable.
--
tibob
# login screen?
Posté par Stephane Chauveau . Évalué à 8.
La faille donne access au 'login screen'. De la on peut obtenir une liste d'utilisateurs. Reste a obtenir un mot de passe.
[^] # Re: login screen?
Posté par Anonyme . Évalué à 9.
Là, il est dit que « cette faille permet une connexion en root sur le système attaqué. »
[^] # Re: login screen?
Posté par rycks . Évalué à 7.
J'ai bien lu la news mais je n'ai pas vu de trace de ce root-exploit !
Éric
eric.linuxfr@sud-ouest.org
[^] # Re: login screen?
Posté par DPhil (site web personnel) . Évalué à 7.
Tout simplement parce que sur la Mandrake 8 on peut se logger en root à partir de KDM ou de GDM (ce qui ne devrait pas être possible), encore faut il avoir le mot de passe.
[^] # Re: login screen?
Posté par philip . Évalué à 10.
moi j'ai le même probleme avec mon appart, si quelqu'un arrive devant ma porte avec ma clef il peut rentrer chef moi... chez une faille importante des systemes appelés "portes"...
[^] # Re: login screen?
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
[^] # Re: login screen?
Posté par daniel . Évalué à 3.
pour ne donner que les plus connues (par moi ) :
- linuxconf (beaucoup l'utilisent moi je suis pas fan)
- l'interface gnome de debconf sous debian (miam)
- ethereal (que du bonheur)
- phpmyadmin et webmin (je sais c'est des interfaces web mais avec w3m je suis pas sur du résultat)
sans parler de la nécessité de temps à autre pour un admin d'éditer des fichier de conf. les éditeur de texte dans la console c'est bien mais ça fatigue à la longue, et il y a trop de raccourcis clavier à apprendre pour faire des trucs aussi simples que couper/copier/coller. la souris ça peut servir...
c'est vrai qu'ici on est des linusque lordz, on utilise que la console et on code qu'en assembleur parce que le C c'est pour les branleurs.
:wq
[^] # Re: login screen?
Posté par Gauthier Monserand (site web personnel) . Évalué à 3.
a bon.
c'est connu, linux c'est nul, on peut pas lancer des applis root sous X si on est en user.
On est pas sous MS mon gars..
--
ps j'aime pas le logo linuxfr
[^] # Re: login screen?
Posté par pasBill pasGates . Évalué à 2.
runas.exe
[^] # Re: login screen?
Posté par daniel . Évalué à 0.
oui c'est warlordzzzz. heu non je déconne.
personnellement je me méfie de ces commandes parce que je ne les connais pas bien : je parle pas de l'utilisation (qui n'est vraiment pas compliquée) , mais du fait que ça mixe les environnements utilisateur et root et que je trouve pas ça très propre.
par exemple :
j'ai mis les locales pour les utilisateurs en français, mais je laisse les locales de root à "C" parce qu'un certain nombre d'applications présente des bugs quand on change de langue.
quand je lance su -c command, je ne suis jamais sur de la valeur des locales.
d'autres part j'ai vu des applications qui déconseillaient l'utilisation de su et sudo.
dans le doute j'utilise peu su*. quand je suis logué en utilisateur je ne suis pas root et vice versa.
ce que je ne comprend pas c'est : qu'y a-t-il de mal à se loguer sous X en root ?
pour une connexion en local je vois pas le mal, franchement.
pour la connexion distante, le password va sur le réseau en clair ( comme n'importe quelle connexion ssh avec authentification par mot de passe), mais le reste de la session utilise un agent ssh, je crois (confirmation ?).
[^] # Re: login screen?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
[^] # Re: login screen?
Posté par Mathieu Millet (site web personnel) . Évalué à 3.
C'est bien connu que SSH transmets les mots de passe en clair. gniiii :op
Désolé de te decevoir, mais ssh établit un tunnel chiffré entre les deux ordinateurs (désolé, je ne me rappelle plus de l'algorithme - peut-etre du Diffie-Hellman que je verais bien s'appliquer ici) avant l'authentification de l'utilisateur. L'utilisateur peut ainsi saisir son mot de passe en toute sécurité.
Sinon, tu m'expliques l'interêt de ssh par rapport à telnet ???
[^] # Re: login screen?
Posté par daniel . Évalué à 1.
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
"tunneled clear text password" c'est un peu ambigu comme expression.
l'interet de ssh par rapport à telnet, je le voyais parce qu'il chiffrait quand même tout le reste de la transaction et qu'on peut se connecter en utilisant la paire clef publique/ clef privée, qu'on peut faire du transfert de fichier avec scp et sftp, que la communication est compressée, sans parler du "forward X11"...
[^] # Re: login screen?
Posté par #3588 . Évalué à 2.
C'est pourtant beaucoup plus propre, si si, ça permet de ne lancer en tant que root que le strict minimum, et pas des dizaines de trucs que tu auras inévitablement en se logeant avec root sous X.
d'autres part j'ai vu des applications qui déconseillaient l'utilisation de su et sudo.
Déconsillé mais par rapport à quoi ? La solution conseillée n'est pas plutot d'utiliser une console plutot que d'utiliser su ? Dans ce cas c'est mieux, c'est sur, si on n'a pas besoin d'X, mais je ne pense pas qu'on puisse conseiller le login X root par rapport à su.
[^] # Re: login screen?
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Il faut utiliser su, ou sudo :
Par exemple j'ai en alias :
alias xcdroast='sudo xcdroast'
Avec comme conf sudoers :
User_Alias GENTILS = annah
Cmnd_Alias X = /usr/bin/ethereal, /usr/bin/gpowertweak, /usr/bin/xcdroast
GENTILS ALL = NOPASSWD: X
Ainsi les applis X autorisées tournent en root sans qu'on est besoin d'exporter des DISPLAY et autres.
[^] # Re: login screen?
Posté par Christophe --- . Évalué à 1.
Je te propose ceci :
Et voila, c'est fini :) A partir de maintenant, tous les utilisateurs dans ce groupe peuvent accéder au graveur, et ce sans avoir besoin de lancer le programme en root.
Et pis... lancer xcdroast en root... quelle drole d'idée : t'as essayé de graver l'iso qui s'appelle /etc/shadow ? si tu le peux, tues users le peuvent aussi :(
[-1: car je suis vraiment off-topic, là...]
[^] # Re: login screen?
Posté par gc (site web personnel) . Évalué à 9.
[^] # Re: login screen?
Posté par PLuG . Évalué à 2.
rien ne t'empeche d'utiliser pop/imap/telnet/ssh/rsh/rlogin/...
pour faire ton attaque brute-force et valider les mots de passe.
voir de profiter d'un cgi a la con ou d'un mot de passe dans squid, .. bref ca laisse des possibilitées.
(meme si je trouve l'annonce un peu dramatisante, ce probleme en lui seul n'en est pas vraiment un).
# C'est quoi, ce délire ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
En plus, de ce que j'ai vu, les configurations par défaut de xdm, gdm et wdm ne sont aucunement concernées par cette « faille ».
Encore des consultants professionnels qui veulent jouer au malin en trouvant la faille qui tue...
[^] # Re: C'est quoi, ce délire ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 10.
[^] # Re: C'est quoi, ce délire ?
Posté par pasBill pasGates . Évalué à 6.
C'est surement pas le probleme de securite le plus important de l'univers, mais ca donne des infos sensibles(logins des users), c'est pas visible a l'utilisateur, et en cela c'est une faille meme si c'est pas l'equivalent d'une elevation de privilege.
[^] # Re: C'est quoi, ce délire ?
Posté par Jar Jar Binks (site web personnel) . Évalué à 4.
[^] # Re: C'est quoi, ce délire ?
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 8.
De la a trouver qu'on peut faire une brute attack sur le systeme, et que c'est un trou de sécurité, c'est fort.
et je confirme que malgré que ca soit le CERT qui ait relayé la news, c'est issu d'un groupe de consulting pas tres connu: www.procheckup.com
Je me demande ce qu'ils ferons comme annonce, le jour où ils vont découvrir que les mdp passent en clair sur le réseau avec xdmcp....
[^] # Re: C'est quoi, ce délire ?
Posté par gle . Évalué à 6.
Une fois que la news a été relayée par Prochecup, le CERT et LinuxFr, évidemment, le rapport Signal/Bruit a forcément légèrement augmenté.
[^] # Re: C'est quoi, ce délire ?
Posté par Vivi (site web personnel) . Évalué à 3.
# new bizarre
Posté par gc (site web personnel) . Évalué à 10.
- à la fin des explications ils sous-entendent que peut-être que Suse et IRIX aussi sont vulnérable, on ne sait donc pas trop quelles "distribs" d'unix/linux ont été testées
- ils sous-entendent qu'on peut avoir un root login, ce qui est faux a priori puisque ça donne juste un login screen
Ceci dit, c'est vrai que ce n'était probablement pas une bonne idée de mettre ça par défaut, et toutes les distribs proposent en général leur dernière version avec cette caractéristique désactivée.
[^] # Re: new bizarre
Posté par Sylvain Rampacek (site web personnel) . Évalué à 4.
- avant la mdk 8.1, xdmcp était activé par défaut (kdm).
- par contre, la mdk 8.1 a fait changer cela... elle désactive par défaut xdmcp.
Après, n'ayant pas de red hat d'installée en ce moment, je ne peux pas vérifier avec la red hat 7.2...
[^] # Re: new bizarre
Posté par anonyme512 . Évalué à 2.
la Mdk 8.1 et 8.2 ne sont pas sensibles au problèmes, ainsi que la RH 7.2
il est à noter que le fonctionnement de kdm, qui est utilisé par défaut suur les mdk est complètement différent sur la 8.0- et la 8.1+:
en 8.0-, kdm est un simple ripoff de xdm et utilise les mêmes fichiers de conf que xdm. c'est dans un de ces fichiers de conf que se situe le "problème", encore une fois, un simple "#" à placer judicieusement.
en 8.1+, kdm est totalement indépendant, et il se trouve que les mecs de Mdk ont par ailleurs configuré correctement kdm par défaut dans le kdmrc (ou peut etre les mecs de kde l'ont fait ainsi).
c tout...
[^] # Re: new bizarre
Posté par Anonyme . Évalué à 1.
Et GDM est par défaut avec le XDMCP désactivé.
# Ha ! Ha ! Quelle bande de branleurs !
Posté par Jean-Yves B. . Évalué à 10.
Alez, comme je suis un seigneur, je vais tenter une traduction (libre) du bout qui me fait marrer :
J'en trouve 42 par seconde des failles comme ça grâce à mon moteur de connerie naturelle.
Encore une boîte qui cherche à vendre sa « solution » de sécurité sur internet et les services associés habituels et lance des advisories sur tout et n'importe quoi pour que le nom de la boîte soit connu.
Le tableau de comparaison de ProCheckUp [1] avec les autres méthodes existantes est un bel exemple de foutage de gueule pas clair aussi (mais pourquoi dans la liste plus bas cela correspond-il à des fonctions d'outils libres ?).
Allez, on leur souhaite bonne chance quand même ...
[1] http://www.procheckup.com/services/faq.html(...)
[^] # Re: Ha ! Ha ! Quelle bande de branleurs !
Posté par Wi][ish . Évalué à 3.
Et n'importe comment qui plus est.
Encore une société "sans gène" prête à faire du profit sur n'importe quoi.
[^] # Re: Ha ! Ha ! Quelle bande de branleurs !
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
Et [-10] a celui qui a proposé la news et a celui qui l'a modéré ! Si seulement ça avait été mis dans la catégoie humour !
[^] # Re: Ha ! Ha ! Quelle bande de branleurs !
Posté par Timbert Benoît . Évalué à 2.
[-1] Pour moi ;-)
[^] # Mea Culpa...
Posté par Nebojsa STOJANOVIC . Évalué à 2.
J'aurais dû effectivement vérifier de plus près mon info...
Mais bon, les références du CERT me semblait suffisante et j'aurai dû gratter un peu plus...
Mais en terme de sécurité il faut avouer, que la récupération des UID et suffisante pour récupérer au moins un compte en faisant du Brutal Force Cracking basé sur un dico ( pour le mot de passe, si certaines règles en dures ne sont pas établies, on a souvent du médore ou autre comme mot de passe..)...
Il me semble que cela affaiblit la sécurité.
La prochaine fois, si mon info et de la même veine, je le jure, je me coupe la couille gauche....
Faut pas en faire un fromage quand même, je me colle un [-30] et je retourne gober une dizaine d'huîtres...
Ki veut me fesser avec une pelle....
;o)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.