A cause d'une mauvaise gestion des arguments trop longs, la fonction d_path() des noyaux Linux jusqu'au 2.2.20 et 2.4.18 permettent l'execution des processus avec des privilèges usurpés. Pensez à mettre à jour !
Pour l'instant on ne peut pas trop mettre à jour... la série 2.2 va jusqu'au 2.2.20, et la 2.4 jusqu'au 2.4.18 !
Il n'y a rien à faire sinon attendre le prochain noyau, en se disant que cette fois-ci on a une bonne raison pour migrer.
exemple de chose réalisable avec cette faille : lister le contenu d'un répertoire auquel on n'a pas accès normalement. En théorie, on devrait aussi pouvoir le faire via des démons, par exemple avec un serveur web filtrant mal les arguments en faisant un GET /argument qui sera passé à d_path().
Donc ceux qui réagissent en disant "ce n'est qu'une faille locale, j'ai que moi comme utilisateur donc je m'en fous" (si si, il y en a ;) se trompent.
meme si la serie 2.2 va jusqu'a 20 et la 2.4 jusqu'a 18, un patch va sortir d'ici peu; donc mettre a jour ne veut pas forcement dire "attendre le 2.4.19".
Pour l'instant on ne peut pas trop mettre à jour... la série 2.2 va jusqu'au 2.2.20, et la 2.4 jusqu'au 2.4.18 !
Et la commande patch ça sert à quoi ? T'es pas obligé d'attendre qu'une nouvelle release officielle du noyau sorte pour appliquer un patch... tu prends tes petites mains, tu appliques un patch (ou en code un s'il n'y en a pas), et tu recompiles... c'est aussi ça le boulot d'un admin, pas rester les bras croisés en attendant qu'une solution tout prète se présente. On est pas chez MS, pieds et poings liés à devoir attendre le patch officiel, on est dans le logiciel libre ici, on a accès au code source.
ouaips, mais justement, pour l'instant il n'y a pas de patch... et je pense que le patch va prendre la forme d'un patch-2.4.19 et patch-2.2.21.
Coder moi-même le patch, je pense que ca rentre pas trop dans mes fonctions d'admin, les serveurs dont je m'occupe sont assez critiques ;-) Je préfère laisser faire ceux qui connaissent très bien le noyau, ils feront moins de conneries que moi...
Et bien on a pas la même conception du métier d'admin. Un admin ne doit pas seulement connaitre la conf d'Apache et apt-get, il doit aussi connaitre assez bien le système qu'il utilise - son fonctionnement interne je veux dire -, la prog système et le langage C. Et faire un patch provisoire pour ce genre de choses, oui, ça rentre dans le boulot d'un admin. Je parle d'un admin professionel qui fait ça a plein temps bien sur, pas de quelqu'un qui fait un peu d'admin en plus du reste.
Effectivement on n'a pas la même conception du métier d'admin. Pour moi, faire de l'admin c'est maitriser les différents produits utilisés ainsi que leur configuration, maintenir le tout à jour, appliquer les patchs quand ils sortent, développer ses propres outils d'admins.
Oui, mon métier est admin. A temps plein. Mais non, je ne connais pas suffisament le code source des produits que j'utilise pour écrire moi-même les patchs sécurité. Si t'es capable de patcher le noyau linux, squid, apache, php, zlib, postfix, proftpd, rsync, etc... sur des serveurs critiques avant le patch officiel, chapeau.
Je sais lire un code source, appliquer un patch à la main, mais ce n'est pas en lisant un source de temps en temps qu'on en maitrise le concept et les implications des modifications. Je préfère laisser ça aux développeurs du produit - à moins qu'il ne s'agisse d'un produit qui m'intéresse pour d'autres raisons et pour lequel je connais son fonctionnement interne - auquel cas oui, je me risquerais à faire un patch.
A priori dès qu'un bug sort sur ce genre de produit (ie avec plus d'un développeur), les développeurs cherchent à corriger le problème. Si je commence à chercher où se trouve la faille dans le source, comment patcher sans faire foirer les trucs à côté, tester sur une config de test pour minimiser l'impact sur la production... avant la fin de ma recette le patch officiel sera sorti. Donc non, faire des patchs suite à des failles de sécurité ce n'est pas mon métier.
Par contre oui, patcher pour ajouter des fonctionalités à un produit fait partie de ma tâche d'admin. Mais à ce moment là j'ai tout mon temps pour lire le source, comprendre sa logique, tester mon patch, etc...
Parce que tu fais des patchs pour rajouter des fonctionnalités et pas pour corriger des trous de sécurités ? Corriger un trou de sécurité c'est souvent quelques lignes de code, qui ne nécessitent pas une connaissance complète du système. Pour ce trou là, c'est juste renvoyer une erreur au lieu de succès quand le path a été tronqué... c'est beaucoup plus simple et beaucoup moins risqué que de rajouter des fonctionnalités.
>un trou de sécurité c'est souvent quelques lignes de code
As tu deja corrige une faille de securite?
> qui ne nécessitent pas une connaissance complète du système
C'est tres recommande.
[..]Corriger un trou de sécurité c'est souvent quelques lignes de code qui ne nécessitent pas une connaissance complète du système[..]
Si seulement vous pouviez avoir raison, apres tout, ce serait beaucoup plus simple.
Seulement, autant il peut s'agir des trous triviaux a corriger, du fait qu'ils proviennent d'une faute d'inattention du codeur, trous qui peuvent sauter aux yeux, lors d'un simple audit du code, par un lecteur avise ou non. Autant il peut s'agir d'une remise en question du design original du code, et la je pense que vous faites fausse route.
En ce qui concerne vos affirmations sur les taches que devrait pouvoir remplir un administrateur, je reste sans mot, aussi je ne commenterais pas.
PS: si j'en juge par la qualite de vos posts sur LKML, vous etes tout pardonne puisque tout ceci vous depasse.
Je n'ai jamais dit que *tous* les trous de sécu étaient simples à corriger, j'ai dit qu'ils l'étaient *souvent*. Beaucoup de trous sont dus à une vérification manquante, un strcpy au lieu d'un strncpy, ou ce genre de choses, et se corrigent en quelques lignes. Bien sûr que certains trous sont beaucoup plus complexes à corriger. Dans le cas présent, il ne s'agit pas d'un trou de conception, et ça ne doit donc pas être extrêment compliqué de corriger.
si j'en juge par la qualite de vos posts sur LKML, vous etes tout pardonne puisque tout ceci vous depasse.
Vous ? c'est qui le vous ?
Si c'est moi, déjà ce sera bien le première fois que je vois des gens se vouvoyer sur DLFP, et ensuite à part quelques bugs reports et un point godwin, je n'ai jamais rien posté sur la LKML... je lis rapidement c'est tout...
si les root aimaient patcher, ils se lèveraient sur leurs petites pattes arrières, zyeuteraient le code source et feraient du bon vi.
au lieu de ça, les root fument des pétards, jouent au babyfoot et grippent au plafond.
Euh... ça sert à quoi de voter [-] sur les posts auto-censurés à -1 ??? Le post précédant c'était de l'humour, proprement mis à -1... Enfin, vous faites ce que vous voulez, mais je crois que vous avez mal compris l'utilité du vote [-] et la signification de la case -1
C'est dingue de voir à chaque news sur un trou de sécu la même rengaine... On est pas chez microsoft ici. On ne protège pas les gens en leur cachant la vérité. S'il y a un trou, il *faut* diffuser l'information le plus possible. Pour que les admins aussi soient au courant, et pas juste une poignée de personne.
Après libres à eux de prendre les mesures qu'il faut: couper temporairement certains services, faire un patch provisoire eux-mêmes, ... mais dissimuler des informations n'a jamais servi qui que ce soit, à part ceux qui possèdent déjà cette information.
Ou, quand on dit savoir ce que le boulot, refiler sa solution aux autres afin qu'ils puissent en profiter et/ou l'ameliore.... wait and see kilo, parle moins, et file nous une soluce...
La solution? Déclarer les bugs quand on les voit. Ce n'est pas en se voilant la face qu'un soft évolue.
Soit on dit "Linux a un bug a tel endroit" et quelques dévellopeurs essaient d'y remédier, et ça peut aller trés vite, soit la personne qui a découvert la faille ne dit rien jusqu'à ce qu'elle ai trouver la faille et dans ce cas ça peut prendre du temps.
Dans le premier cas, ça peut permettre aux admin de couper certains services jusqu'à l'arrivé d'un patch, dans le second, les admin n'étant pas au courant ne font rien.
Oui, oui on a comprit... J'ai pas dit le contraire
En reprennant les discutions de Mr Kilo* on voit qu'il dit carrement que l'admin DOIT savoir faire un p'tit patch vite fait (Et tant pis si il sait pas, c'est pas un vrai2vrai), et attendant les officels.
Donc je lui demandais juste de se bouger et de nous le filer le sien des qu'il aurait fini :^) la...
Kilo* ? Pourquoi ne pas dire mon pseudo complet ? Tu as peur d'invoquer un démon majeur ? :)
dit carrement que l'admin DOIT savoir faire un p'tit patch vite fait
Oui. Enfin, relativisons. Je ne dis pas qu'un admin doit être capable de tout patcher, mais dans beaucoup de cas, les trous de sécurités sont dus à des oublis ou des étourderies et se patchent très simplement pour qui connaît bien le C. Or, oui, je l'affirme une bonne connaissance du langage C est nécessaire pour être administrer une machine Unix sensible.
Donc je lui demandais juste de se bouger et de nous le filer le sien des qu'il aurait fini :^) la...
Je ne suis pas admin (sinon je serais dans le code entrain de faire un patch là...)
Faut aussi savoir souder au cas ou une carte grille et qu'on puisse réparer en soudant une chtite résistance par-ci par-là en attendant de recevoir la bonne pièce.
Certes il ne faut pas minimiser l'impact de cette faille ... mais:
elle depend d'un débordement de buffer sur les noms de chemin. Pour l'activer, il faut quand meme créer en local (peut etre sur un drive reseau aussi) une arborescence de fou.
la faille c'est que le noyau, au lieu de renvoyer une erreur, renvoie la taille de son buffer (trop petit) et donc renvoie un chemin tronqué.
A priori ce sera difficile a exploiter a distance, puisqu'il faut avoir le droit de creer des repertoires imbriqués sur la machine.
Cela ne signifie pas que c'est impossible si vous hebergez un serveur FTP avec droit en écriture par exemple.(encore que la création de repertoires imbriqués n'est pas conseillée sur les serveurs FTP).
Ben non, pas tant que ça, puisque je doute que le kernel traite en interne la résolution de noms de fichiers relatifs.
Techniquement, ce "zig-zag" doit parfaitement marcher.
A tester
(et je n'oublierai plus le "m" de "grimper", ni de citer les nuls, ni d'indiquer mes "-1", ni de remercier tous les gentils scoreurs qui ont de l'humour)
C'est fou comme on trouve des bugs c'est temps-çi !! J'en reviens toujours pas.. Mais ça veux dire qu'y a plus de monde qui utilise du libre! On va enfin pouvoir montrer la puissance du libre : à savoir,un temps de résolution de problème imbattable :P
Mais j'avoue que des fois,j'ai envie de sauter sur les BSD(openbsd pour les paranos ou freebsd pour les gens "normaux") pour quelques temps le temps que la marée de gros bugs linux passe :|
nan a priori c'est problematique sur les programmes priviligies (lance en droit root ou setuid root) qui font certaines operations sur le systeme de fichier (chdir, readlink, etc). donc a ce que j'en ai vu c'est pas grave.
Pas si souvent que ça,mais on a vu de bugs(pas necessairement majeur) qui on fait des belles surprises sur les forums(ici aussi il me semble)!
Des bugs qu'on pensaient impensable!! Mais c'était des bugs applicatifs dans la plupars des cas et qui touchait plusieurs plateformes(openssh dernièrement) autre que linux :)
J'avoue être encore très novice(je me perd encore dans KDE et Gnome) et je peux avoir une fausse idée de la situation...eeeh,juste comme ça,y en a pas qui trouve que KDE et Gnome sont pas très pratique?? J'en viens à penser que la ligne de commande est moins compliqué ^_^ ...
Oui, mais par exemple, le bug de la zlib dont on a parlé récemment est susceptible de toucher aussi les applis Microsoft qui l'utilisent. C'est de l'OpenSource, mais pas lié à Linux spécifiquement.
Linuxfr a arrêté de parler des failles de sécurité des produits Microsoft en ce qui concerne IE, IIS, Outlook, etc, et c'est logique, mais ce n'est pas parce qu'une faille est révélée ici qu'elle est à imputer au noyau Linux.
> openbsd pour les paranos
Je ne suis pas d'accord. OpenBSD est avant tout un OS stable et a mon sens, excellement documente (jetez un coup d'oeil aux pages de man).
> freebsd pour les gens "normaux"
Je ne pense que les utilisateurs d'unix libres soient dans la normalite pour l'instant.
>Je ne suis pas d'accord. OpenBSD est avant tout un OS stable et a mon sens, excellement documente
hmm...Openbsd est très stable et pas de bugs de sécurité dans l'installation par défaut depuis plus de 2 ans si j'ai bien saisie :P
Mais c'est la cryptographie en natif qui tue selon moi et j'aime à m'imaginer qu'un VNP avec Openbsd soit "pratiquement" inviolable s'il est bien configuré :P
J'aimerais faire un firewall avec openbsd,je pense pouvoir dire sans me tromper que le hacker qui va s'essayer à me rentrer dedans avec ça ,va en ch... un max ;D
>Je ne pense que les utilisateurs d'unix libres soient dans la normalite pour l'instant.
Touché !! Parfaitement d'accord :)))
La normalité,c'est extrèmement relatif !!!
Plus on est fou,mieux que c'est,sinon,la vie est un peu morne....
En fait, je crois que c'est plutôt aucun trou de sécurité "remote" dans l'install par défaut.
Pour autant, on ne peut pas dire pour autant que les démons soit parfaitement sécurisés, je crois me souvenir d'une faille sur Bugtraq concernant serveur FTP d'OpenBSD il y a un an. Elle ne comptait pas, car le serveur FTP n'était pas dans
l'install par défaut.
Les multiples race conditions dans le noyau (similaire à celle que l'on avait trouvé dans Linux) ne comptent pas non plus car elles sont "locales".
En fait, j'ai l'impression que l'install par défaut n'installe aucun programme accessible en "remote", d'ou le fameux slogan qui permet de dire : OpenBSD, c'est le serveur ne servant à rien le plus sécurisé de la planète.
Ils ont pas trouvé une faille (off by one je crois) récemment dans SSH (auth.c)
Comment ça se fait qu'OpenBSD n'est pas concerné, ils sont pas vulnérables ou bien c'est quand leur histoire d'install par défaut qui fait que "celle-la elle compte pas" ?
J'ai pas vu de trou de sécurité dans un caillou depuis au moins 4 milliards d'année. Le caillou est mieux sécurisé. Et en plus y'a même pas besoin de l'installer.
La tres grande majorité des bugs sous linux (GNU/Linux) sont des bugs applicatifs. Donc des bugs que tu retrouvera surement sous *BSD (php, zlib, etc...).
Mais si ça te rassure passe sous *BSD.
Tu peux aussi faire la politique de l'autruche :
- utiliser Windows
- ne visiter que www.microsoft.com
C'est vrai,j'aurais dût spécifier que les bugs était applicatifs :( mais j'ai pas pensé à le faire,désolé !
Mais si je passe sous BSD(oui,si),ça va surement pas pour être rassuré!! Je me suis senti un peu insulté par cette déclaration,mais ,vu que tu me connais pas c'est compréhensible et je passe la main :)
J'avoue être chatouilleux sur ce point là: me faire dire que je suis un lâche dans ce que je fait(même si des fois,ça peut être justifié)...
>Tu peux aussi faire la politique de l'autruche :
>- utiliser Windows
>- ne visiter que www.microsoft.com
OUCH!! Celle-là, elle à fait VRAIMENT mal >:|
Je sais pas dans quel sens tu me dit ça mais devant mon clavier, je me sent insulté en caliss(terme quebecois) !!!
J'ai vraiment pas aimé ,précise si tu le veux bien si j'ai pas bien interprété !
Pour ton information, je suis dans un cours d'administrateur de réseau et télécoms ,et j'apprend actuellement win2000 serveur ET ÇA ME FAIT ROYALEMENT CHIER(désolé...) !!!!
J'apprend cisco dans 1 mois(c'est un cours de 1 ans compressé) et c'est un cours assez plein,j'ai pas beaucoup de temps pour moi(entre l'école et les dépannages,ouf). Mais j'essaie d'apprendre les logiciels libres et la philosophie du libre du mieux que je peux et ça aide pas de se faire descendre comme tu viens de le faire...
C'est "presque" impardonnable et c'est indigne d'un "evêque" ....
D'après ce que j'ai vu, à part le process perd les pédales et sait plus où il est, c'est pas encore trop trop méchant... Il y a des processes que cela ne devrait pas gêner (notament certain démons qui se positionnent dans un répertoire avant de faire quoi que çe soit). Attention quand même à argv[0] !
Et puis on lance rarement des process root n'importe comment.
Ben moi, sur certains serveurs, j'ai une 60aine d'apaches qui tournent, presque autant de ftpd, et pis sans compter les php en su-exec, donc qui se positionnent effectivement dans un répertoire donné... Le mutualisé, c'est très sensible aux DoS :(
je viens de lire un truc assez fort sur toolinux.com .
Mandrake a fait paraitre par voix de presse un communiqué expliquant que staroffice 6.0 n'est intégré que dans les versions pro de mandrake oem[..]
Selon l'accord passé avec Sun, Mandrake devait mettre aussi à disposition des adhérents de son club (dont on avait parlé il y a quelques jours) Staroffice en Oem...
Seulement, ça leur prendrait trop de ressources... Ils ont donc décidé de mettre à disposition Staroffice uniquement pour les adhérents Silver ...
Comme quoi c est bien beau de racoler un max de personnes, et de faire appel à la bonté des utilisateurs en leur disant que peu importe leurs contributions on a les meme avantages...
Si je ne me trompe pas c est de la publicité mensongère.
C'est trop dur de poster les commentaires dans les bonnes news ?
En l'occurence, la news sur Mdk & SO6 est là : http://linuxfr.org/2002/03/26/7702,0,-1,0,1.php3(...) .
Tout ce que tu fais là, c'est du hors-sujet.
c pas pour faire chier le peuple, mais à mettre quake3VersionHardcoreBigboobs.o dans le kernell, c'est pas la grosse surprise que y'ait des bugs qui apparaissent
sérieusement, p-e le temps de penser que le kernel est un kernel, c'est pas la place ppur mettre des choses genre TUX
au pire, que les codeurs le concoivent pour qu'il puisse marcher en noyeau, cool!, mais que le monde veuillent l,avoir dans le kernell oficiel, là...
ça s'applique p-e pas ici, vu que ça l air du fct de bas niveau et indispensable, mais la déferlante de bug commence à m énerver un peu
dans le fond, les microkernel, c est vrai que théoriquement, c mieux que le mono
# Mettre à jour...
Posté par Yann Hirou . Évalué à 10.
Il n'y a rien à faire sinon attendre le prochain noyau, en se disant que cette fois-ci on a une bonne raison pour migrer.
exemple de chose réalisable avec cette faille : lister le contenu d'un répertoire auquel on n'a pas accès normalement. En théorie, on devrait aussi pouvoir le faire via des démons, par exemple avec un serveur web filtrant mal les arguments en faisant un GET /argument qui sera passé à d_path().
Donc ceux qui réagissent en disant "ce n'est qu'une faille locale, j'ai que moi comme utilisateur donc je m'en fous" (si si, il y en a ;) se trompent.
[^] # Re: Mettre à jour...
Posté par Victor Vuillard . Évalué à 10.
[^] # Re: Mettre à jour...
Posté par Gaël Le Mignot . Évalué à -2.
Et la commande patch ça sert à quoi ? T'es pas obligé d'attendre qu'une nouvelle release officielle du noyau sorte pour appliquer un patch... tu prends tes petites mains, tu appliques un patch (ou en code un s'il n'y en a pas), et tu recompiles... c'est aussi ça le boulot d'un admin, pas rester les bras croisés en attendant qu'une solution tout prète se présente. On est pas chez MS, pieds et poings liés à devoir attendre le patch officiel, on est dans le logiciel libre ici, on a accès au code source.
[^] # Re: Mettre à jour...
Posté par Yann Hirou . Évalué à 10.
Coder moi-même le patch, je pense que ca rentre pas trop dans mes fonctions d'admin, les serveurs dont je m'occupe sont assez critiques ;-) Je préfère laisser faire ceux qui connaissent très bien le noyau, ils feront moins de conneries que moi...
[^] # Re: Mettre à jour...
Posté par Gaël Le Mignot . Évalué à -10.
[^] # Re: Mettre à jour...
Posté par Yann Hirou . Évalué à 10.
Oui, mon métier est admin. A temps plein. Mais non, je ne connais pas suffisament le code source des produits que j'utilise pour écrire moi-même les patchs sécurité. Si t'es capable de patcher le noyau linux, squid, apache, php, zlib, postfix, proftpd, rsync, etc... sur des serveurs critiques avant le patch officiel, chapeau.
Je sais lire un code source, appliquer un patch à la main, mais ce n'est pas en lisant un source de temps en temps qu'on en maitrise le concept et les implications des modifications. Je préfère laisser ça aux développeurs du produit - à moins qu'il ne s'agisse d'un produit qui m'intéresse pour d'autres raisons et pour lequel je connais son fonctionnement interne - auquel cas oui, je me risquerais à faire un patch.
A priori dès qu'un bug sort sur ce genre de produit (ie avec plus d'un développeur), les développeurs cherchent à corriger le problème. Si je commence à chercher où se trouve la faille dans le source, comment patcher sans faire foirer les trucs à côté, tester sur une config de test pour minimiser l'impact sur la production... avant la fin de ma recette le patch officiel sera sorti. Donc non, faire des patchs suite à des failles de sécurité ce n'est pas mon métier.
Par contre oui, patcher pour ajouter des fonctionalités à un produit fait partie de ma tâche d'admin. Mais à ce moment là j'ai tout mon temps pour lire le source, comprendre sa logique, tester mon patch, etc...
[^] # Re: Mettre à jour...
Posté par Gaël Le Mignot . Évalué à -10.
[^] # Re: Mettre à jour...
Posté par Laurent Laborde (site web personnel) . Évalué à -9.
Je doute meme que tu sois admin d'ailleur ...
--
Ker2x
[^] # Re: Mettre à jour...
Posté par Delaregue . Évalué à 10.
As tu deja corrige une faille de securite?
> qui ne nécessitent pas une connaissance complète du système
C'est tres recommande.
[^] # Re: Mettre à jour...
Posté par Dawood Ibrahim . Évalué à 10.
Si seulement vous pouviez avoir raison, apres tout, ce serait beaucoup plus simple.
Seulement, autant il peut s'agir des trous triviaux a corriger, du fait qu'ils proviennent d'une faute d'inattention du codeur, trous qui peuvent sauter aux yeux, lors d'un simple audit du code, par un lecteur avise ou non. Autant il peut s'agir d'une remise en question du design original du code, et la je pense que vous faites fausse route.
En ce qui concerne vos affirmations sur les taches que devrait pouvoir remplir un administrateur, je reste sans mot, aussi je ne commenterais pas.
PS: si j'en juge par la qualite de vos posts sur LKML, vous etes tout pardonne puisque tout ceci vous depasse.
[^] # Re: Mettre à jour...
Posté par Gaël Le Mignot . Évalué à -1.
si j'en juge par la qualite de vos posts sur LKML, vous etes tout pardonne puisque tout ceci vous depasse.
Vous ? c'est qui le vous ?
Si c'est moi, déjà ce sera bien le première fois que je vois des gens se vouvoyer sur DLFP, et ensuite à part quelques bugs reports et un point godwin, je n'ai jamais rien posté sur la LKML... je lis rapidement c'est tout...
[^] # Re: Mettre à jour...
Posté par Code34 (site web personnel) . Évalué à -10.
http://www.kip.ru/s/daemons/takeittux.jpg(...)
@+
Code34
[^] # Re: Mettre à jour...
Posté par youpi_youpi . Évalué à -1.
[^] # devenir admin par la méthode coué
Posté par Code34 (site web personnel) . Évalué à -3.
@+
Code34
hé oui la méthode coué s'applique aussi aux admins [..]
[^] # ouais moi aussi je patche!
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 10.
au lieu de ça, les root fument des pétards, jouent au babyfoot et grippent au plafond.
ok ok ok ok
[^] # Message aux scoreurs
Posté par Gaël Le Mignot . Évalué à -10.
-1 car complètement HS
[^] # Re: Message aux scoreurs
Posté par TSelek . Évalué à -1.
-1 aussi mais comme tu le dis ça ne sert à rien de l'écrire...
[^] # Re: Message aux scoreurs
Posté par Laurent Laborde (site web personnel) . Évalué à -4.
+1 pasque je le veux bien.
--
Kerdezixe
[^] # Re: ouais moi aussi je patche!
Posté par gndl (site web personnel) . Évalué à -4.
[^] # Re: Mettre à jour...
Posté par homoanonymus . Évalué à -10.
Arg ! Et qu'est ce qu'il faut faire en attendant ?
C'est pas un peu dangereux d'annoncer à tout le monde une faille sans qu'il y ait de solution ?
A moins de verrouiller...
[^] # Re: Mettre à jour...
Posté par Gaël Le Mignot . Évalué à 10.
Après libres à eux de prendre les mesures qu'il faut: couper temporairement certains services, faire un patch provisoire eux-mêmes, ... mais dissimuler des informations n'a jamais servi qui que ce soit, à part ceux qui possèdent déjà cette information.
[^] # Re: Mettre à jour...
Posté par Yohann (site web personnel) . Évalué à 6.
[^] # Re: Mettre à jour...
Posté par Rin Jin (site web personnel) . Évalué à 10.
Soit on dit "Linux a un bug a tel endroit" et quelques dévellopeurs essaient d'y remédier, et ça peut aller trés vite, soit la personne qui a découvert la faille ne dit rien jusqu'à ce qu'elle ai trouver la faille et dans ce cas ça peut prendre du temps.
Dans le premier cas, ça peut permettre aux admin de couper certains services jusqu'à l'arrivé d'un patch, dans le second, les admin n'étant pas au courant ne font rien.
[^] # Re: Mettre à jour...
Posté par Yohann (site web personnel) . Évalué à 6.
En reprennant les discutions de Mr Kilo* on voit qu'il dit carrement que l'admin DOIT savoir faire un p'tit patch vite fait (Et tant pis si il sait pas, c'est pas un vrai2vrai), et attendant les officels.
Donc je lui demandais juste de se bouger et de nous le filer le sien des qu'il aurait fini :^) la...
[^] # Re: Mettre à jour...
Posté par Gaël Le Mignot . Évalué à -3.
Kilo* ? Pourquoi ne pas dire mon pseudo complet ? Tu as peur d'invoquer un démon majeur ? :)
dit carrement que l'admin DOIT savoir faire un p'tit patch vite fait
Oui. Enfin, relativisons. Je ne dis pas qu'un admin doit être capable de tout patcher, mais dans beaucoup de cas, les trous de sécurités sont dus à des oublis ou des étourderies et se patchent très simplement pour qui connaît bien le C. Or, oui, je l'affirme une bonne connaissance du langage C est nécessaire pour être administrer une machine Unix sensible.
Donc je lui demandais juste de se bouger et de nous le filer le sien des qu'il aurait fini :^) la...
Je ne suis pas admin (sinon je serais dans le code entrain de faire un patch là...)
-1 car ça part en ***** ce débat
[^] # Re: Mettre à jour... -1
Posté par Gloo . Évalué à -5.
oui oui... D'ailleurs j'ai le code de solaris et à la moindre alerte j'installe emacs et gcc sur une machine de prex...
-1
[^] # Re: Mettre à jour...
Posté par Noe Reboul . Évalué à 0.
[^] # Re: Mettre à jour...
Posté par ghent . Évalué à 4.
[^] # Re: Mettre à jour... -1
Posté par Gloo . Évalué à 1.
-1
[^] # Re: Mettre à jour... -1
Posté par vieuxshell (site web personnel) . Évalué à 7.
[^] # Re: Mettre à jour...
Posté par Neryel . Évalué à 1.
Bah, il devait oublier que dire 'Kilobug', c'est sans danger tant qu'on dit pas 'GNU' et 'Hurd' dans la même phrase. Ohmerde.
[^] # Re: Mettre à jour...
Posté par homoanonymus . Évalué à -2.
Grace à moi t'as gagné au moins 32 XPs!
----
Homotrollus.
[^] # Re: Mettre à jour...
Posté par PLuG . Évalué à 9.
elle depend d'un débordement de buffer sur les noms de chemin. Pour l'activer, il faut quand meme créer en local (peut etre sur un drive reseau aussi) une arborescence de fou.
la faille c'est que le noyau, au lieu de renvoyer une erreur, renvoie la taille de son buffer (trop petit) et donc renvoie un chemin tronqué.
A priori ce sera difficile a exploiter a distance, puisqu'il faut avoir le droit de creer des repertoires imbriqués sur la machine.
Cela ne signifie pas que c'est impossible si vous hebergez un serveur FTP avec droit en écriture par exemple.(encore que la création de repertoires imbriqués n'est pas conseillée sur les serveurs FTP).
[^] # Re: Mettre à jour...
Posté par Gaël Le Mignot . Évalué à -2.
Je me demande si /home/../home/../home/..... peut permettre de dépasser le buffer même si les noms de fichiers ne sont pas trop longs...
-1 car je dis peut-être une bêtise
[^] # bétise ?!?
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 2.
Techniquement, ce "zig-zag" doit parfaitement marcher.
A tester
(et je n'oublierai plus le "m" de "grimper", ni de citer les nuls, ni d'indiquer mes "-1", ni de remercier tous les gentils scoreurs qui ont de l'humour)
# C'est dingue !!
Posté par Schneider Dark . Évalué à 10.
Mais j'avoue que des fois,j'ai envie de sauter sur les BSD(openbsd pour les paranos ou freebsd pour les gens "normaux") pour quelques temps le temps que la marée de gros bugs linux passe :|
Les forces libre vaincront...
[^] # Re: C'est dingue !!
Posté par Jak . Évalué à 6.
[^] # Re: C'est dingue !!
Posté par Tab Tab . Évalué à -4.
[^] # Re: De Schneider à Jak
Posté par Schneider Dark . Évalué à -2.
Des bugs qu'on pensaient impensable!! Mais c'était des bugs applicatifs dans la plupars des cas et qui touchait plusieurs plateformes(openssh dernièrement) autre que linux :)
J'avoue être encore très novice(je me perd encore dans KDE et Gnome) et je peux avoir une fausse idée de la situation...eeeh,juste comme ça,y en a pas qui trouve que KDE et Gnome sont pas très pratique?? J'en viens à penser que la ligne de commande est moins compliqué ^_^ ...
[^] # Re: De Schneider à Jak
Posté par Jak . Évalué à 1.
Linuxfr a arrêté de parler des failles de sécurité des produits Microsoft en ce qui concerne IE, IIS, Outlook, etc, et c'est logique, mais ce n'est pas parce qu'une faille est révélée ici qu'elle est à imputer au noyau Linux.
[^] # Re: C'est dingue !!
Posté par Delaregue . Évalué à 2.
Je ne suis pas d'accord. OpenBSD est avant tout un OS stable et a mon sens, excellement documente (jetez un coup d'oeil aux pages de man).
> freebsd pour les gens "normaux"
Je ne pense que les utilisateurs d'unix libres soient dans la normalite pour l'instant.
[^] # Re: De Schneider à Delaregue
Posté par Schneider Dark . Évalué à 0.
hmm...Openbsd est très stable et pas de bugs de sécurité dans l'installation par défaut depuis plus de 2 ans si j'ai bien saisie :P
Mais c'est la cryptographie en natif qui tue selon moi et j'aime à m'imaginer qu'un VNP avec Openbsd soit "pratiquement" inviolable s'il est bien configuré :P
J'aimerais faire un firewall avec openbsd,je pense pouvoir dire sans me tromper que le hacker qui va s'essayer à me rentrer dedans avec ça ,va en ch... un max ;D
>Je ne pense que les utilisateurs d'unix libres soient dans la normalite pour l'instant.
Touché !! Parfaitement d'accord :)))
La normalité,c'est extrèmement relatif !!!
Plus on est fou,mieux que c'est,sinon,la vie est un peu morne....
[^] # Re: De Schneider à Delaregue
Posté par Annah C. Hue (site web personnel) . Évalué à 4.
A c't'heure ça fait ben 4 ans qu'y'a pas eu de trous de sécu dans l'install par défaut !
[^] # Re: De Schneider à Delaregue
Posté par Schneider Dark . Évalué à 0.
je m'étais planté,merci
C'est encore mieux que je pensais,mouaahahaaaaa :P
Les forces du libre vaincront...
[^] # OpenBSD
Posté par Anne Onimousse . Évalué à 1.
Pour autant, on ne peut pas dire pour autant que les démons soit parfaitement sécurisés, je crois me souvenir d'une faille sur Bugtraq concernant serveur FTP d'OpenBSD il y a un an. Elle ne comptait pas, car le serveur FTP n'était pas dans
l'install par défaut.
Les multiples race conditions dans le noyau (similaire à celle que l'on avait trouvé dans Linux) ne comptent pas non plus car elles sont "locales".
En fait, j'ai l'impression que l'install par défaut n'installe aucun programme accessible en "remote", d'ou le fameux slogan qui permet de dire : OpenBSD, c'est le serveur ne servant à rien le plus sécurisé de la planète.
[^] # Re: OpenBSD
Posté par Annah C. Hue (site web personnel) . Évalué à 0.
Cependant dans l'install par défaut on a quand même ssh qui écoute dehors. C'est pas rien !
[^] # Re: OpenBSD
Posté par Anne Onimousse . Évalué à 1.
Comment ça se fait qu'OpenBSD n'est pas concerné, ils sont pas vulnérables ou bien c'est quand leur histoire d'install par défaut qui fait que "celle-la elle compte pas" ?
[^] # Re: De Schneider à Delaregue
Posté par VACHOR (site web personnel) . Évalué à 2.
[^] # Re: C'est dingue !!
Posté par matiasf . Évalué à 5.
Mais si ça te rassure passe sous *BSD.
Tu peux aussi faire la politique de l'autruche :
- utiliser Windows
- ne visiter que www.microsoft.com
[^] # Re: De Schneider à matiasf
Posté par Schneider Dark . Évalué à -3.
Mais si je passe sous BSD(oui,si),ça va surement pas pour être rassuré!! Je me suis senti un peu insulté par cette déclaration,mais ,vu que tu me connais pas c'est compréhensible et je passe la main :)
J'avoue être chatouilleux sur ce point là: me faire dire que je suis un lâche dans ce que je fait(même si des fois,ça peut être justifié)...
>Tu peux aussi faire la politique de l'autruche :
>- utiliser Windows
>- ne visiter que www.microsoft.com
OUCH!! Celle-là, elle à fait VRAIMENT mal >:|
Je sais pas dans quel sens tu me dit ça mais devant mon clavier, je me sent insulté en caliss(terme quebecois) !!!
J'ai vraiment pas aimé ,précise si tu le veux bien si j'ai pas bien interprété !
Pour ton information, je suis dans un cours d'administrateur de réseau et télécoms ,et j'apprend actuellement win2000 serveur ET ÇA ME FAIT ROYALEMENT CHIER(désolé...) !!!!
J'apprend cisco dans 1 mois(c'est un cours de 1 ans compressé) et c'est un cours assez plein,j'ai pas beaucoup de temps pour moi(entre l'école et les dépannages,ouf). Mais j'essaie d'apprendre les logiciels libres et la philosophie du libre du mieux que je peux et ça aide pas de se faire descendre comme tu viens de le faire...
C'est "presque" impardonnable et c'est indigne d'un "evêque" ....
[^] # Re: C'est dingue !!
Posté par ours Ours (site web personnel) . Évalué à 2.
# Ca a pas l'air trop trop méchant
Posté par Timbert Benoît . Évalué à 4.
Et puis on lance rarement des process root n'importe comment.
On est loin du root exploit.
[^] # Re: Ca a pas l'air trop trop méchant
Posté par Jak . Évalué à 1.
Et ça permet pas de faire un DoS ?
Enfin, je dis ça, je sais pas, hein...
[^] # Re: Ca a pas l'air trop trop méchant
Posté par Timbert Benoît . Évalué à -3.
[^] # Re: Ca a pas l'air trop trop méchant
Posté par nodens . Évalué à 0.
# a propos de Netscape ;)
Posté par Code34 (site web personnel) . Évalué à -10.
netscape 6.2.x est sorti depuis quelques jours [..]
http://www.netscape.com(...)
@+
Code34
# Mandrake 8.2 vol à l'adhérent ;))
Posté par Code34 (site web personnel) . Évalué à -10.
Mandrake a fait paraitre par voix de presse un communiqué expliquant que staroffice 6.0 n'est intégré que dans les versions pro de mandrake oem[..]
Selon l'accord passé avec Sun, Mandrake devait mettre aussi à disposition des adhérents de son club (dont on avait parlé il y a quelques jours) Staroffice en Oem...
Seulement, ça leur prendrait trop de ressources... Ils ont donc décidé de mettre à disposition Staroffice uniquement pour les adhérents Silver ...
Comme quoi c est bien beau de racoler un max de personnes, et de faire appel à la bonté des utilisateurs en leur disant que peu importe leurs contributions on a les meme avantages...
Si je ne me trompe pas c est de la publicité mensongère.
@+
Code34
[^] # Re: Mandrake 8.2 vol à l'adhérent ;))
Posté par Netsabes . Évalué à 9.
En l'occurence, la news sur Mdk & SO6 est là : http://linuxfr.org/2002/03/26/7702,0,-1,0,1.php3(...) .
Tout ce que tu fais là, c'est du hors-sujet.
(-1, rien à foutre ici)
[^] # Re: Mandrake 8.2 vol à l'adhérent ;))
Posté par matiasf . Évalué à -6.
Le mieux est d'attendre une news relative au sujet ou de proposer une news.
# mauvaise langue
Posté par Croweye . Évalué à -4.
sérieusement, p-e le temps de penser que le kernel est un kernel, c'est pas la place ppur mettre des choses genre TUX
au pire, que les codeurs le concoivent pour qu'il puisse marcher en noyeau, cool!, mais que le monde veuillent l,avoir dans le kernell oficiel, là...
ça s'applique p-e pas ici, vu que ça l air du fct de bas niveau et indispensable, mais la déferlante de bug commence à m énerver un peu
dans le fond, les microkernel, c est vrai que théoriquement, c mieux que le mono
# Zeu patch, made by moi ;-)
Posté par Timbert Benoît . Évalué à 8.
Mais comme j'ai pas une totle maîtrise de la Force, faut voir...
--- /usr/src/linux/fs/dcache.c.orig Fri Nov 2 17:39:08 2001
+++ /usr/src/linux/fs/dcache.c Wed Mar 27 23:30:32 2002
@@ -794,8 +794,11 @@
break;
namelen = dentry->d_name.len;
buflen -= namelen + 1;
- if (buflen < 0)
+ if (buflen < 0) {
+ /* FIXME : buffer overflow -> no return */
+ retval = buffer+buflen;
break;
+ }
end -= namelen;
memcpy(end, dentry->d_name.name, namelen);
*--end = '/';
J'ai testé l'exploit, je me fais pas avoir, moi ;-)
[^] # Re: Zeu patch, made by moi -- laissez tomber
Posté par Timbert Benoît . Évalué à 1.
[^] # Re: Zeu patch, made by moi -- laissez tomber
Posté par Timbert Benoît . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.