un rapide journal pour info :
la faille est apparemment liée à gcc et à certains noyaux.
l'éxécution d'un petit programme en C ferait totalement bloquer la machine.
il suffit d'avoir un compte shell sur la machine (user, meme pas root).
la news est passée sur slashdot, l'article référencé donne des indications sur les noyaux victimes, le code c de l'appli en question, et des patchs.
l'article sur slashdot :
http://slashdot.org/articles/04/06/14/118209.shtml?tid=106&tid=(...)
certains commentaires y sont d'ailleurs hilarants (http://slashdot.org/comments.pl?sid=110983&cid=9418977(...) <- pour ceux qui ont du mal à reconnaitre de l'ironie : ce commentaire est à prendre au second degré)
le thread sur la lkml :
http://marc.theaimsgroup.com/?l=linux-kernel&m=108681568931323&(...)
note : la faille ne toucherait que les x86
Journal faille dans les linux 2.4.2x et 2.6.x
14
juin
2004
# Deja passé..
Posté par Mathieu Pillard (site web personnel) . Évalué à 7.
[^] # Re: Deja passé..
Posté par ange_thom . Évalué à 0.
pas encore l'habitude de regarder systematiquement tous les journaux... faut que je me foute un post it que j'arrete d'oublier une fois sur deux ...
[^] # Re: Deja passé..
Posté par Mathieu Pillard (site web personnel) . Évalué à 6.
http://marc.theaimsgroup.com/?l=bk-commits-head&m=1087096061265(...)
A noter que ca affecte aussi x86-64, c'est la meme chose en fait:
http://marc.theaimsgroup.com/?l=bk-commits-head&m=1087135801308(...)
# Pas d'humour
Posté par Black Fox . Évalué à 1.
# Faille dans tout les noyaux linux et meme ceux a venir
Posté par gnumdk (site web personnel) . Évalué à 2.
while (( 1 ))
do
./t.sh&
done
[gnumdk@milouse gnumdk]$
Perso, si j'attend plus de 15 secondes, je peux plus reprendre la main :)
Quelqu'un parlait dans un journal precedent de limiter le nombre de processus par utilisateur mais meme en en laissant 500 par utilisateur, meme si le systeme refuse de lancer de nouveaux shells, tu auras quand meme plus de 400 while qui tournent en meme temps. Je suis pas sur et j'ai pas envie de tester, mais ca permet de reprendre la main ca? En clair, c'est pas plus simple d'appuyer sur Ctrl + Alt + Suppr que d'attendre 3 jours que login veuillent bien afficher la ligne password, que pam verifie le mot de passe et que bash se lance?
[^] # Re: Faille dans tout les noyaux linux et meme ceux a venir
Posté par Denis Montjoie (site web personnel) . Évalué à 3.
<MODE PARANO>
Moi mes users ils auront que 5% bande de failles ambulantes
Et encore ils pourront se logguer que si je suis la. na!
</MODE PARANO>
ctrl alt suppr cest rapide mais si tu as des applis critique vaux mieux reprendre la main en douceur.
[^] # Re: Faille dans tout les noyaux linux et meme ceux a venir
Posté par Croconux . Évalué à 2.
for(;;)
{
fork();
}
On parle pas mal de cette faille alors qu'elle n'est pas bien méchante. Malheureusement je suis sur que ça va être repris en coeur par MS et compagnie. Sont chiants les gens parfois....
# Bravo linux ...
Posté par Code34 (site web personnel) . Évalué à -1.
"Thanks for the respons. Seems to be harder to get up the eyes of the kernel people, since the floating point exceptions inside that signal handler fucks up the current linux-kernels. Haven't got any respons from any of the kernel developers yet. A bit scary I think. But a big thanks to you atleast for given this some attention."
Cet exploit n'est pas une note d'information, c'est réellement le code en entier, pret à etre compilé , et utilisé par n'importe quel script kiddies.
Il apostrophe d'ailleurs son propre code avec une note disant que ça a permis (depuis 2 jours) de faire sauter des serveurs de shells gratuit de lameur .
Ce comportement est belle et bien celui d'un crasher (pirate), et ça ne rend pas juste aux méthodes de développement du kernel linux.
[^] # Re: Bravo linux ...
Posté par ckyl . Évalué à 10.
C'est cette publication du code qui permet de garder la pression sur les developpeurs des produits incriminés pour que ce soit corrigé. C'est bizarre mais souvent quand tu regardes l'historique des failles ca met un mois a etre corrigé quand tu mail en privé mais 4h quand c'est publique... Pourtant la faille n'est pas moins présente et exploitable.
Après si tu preferes qu'une faille reste dans la communauté black hat pendant 1 ans avant d'etre publique plutot que d'avoir une fenetre de 4 jours ou ta machine est vulnerable libre a toi.
[^] # Re: Bravo linux ...
Posté par Code34 (site web personnel) . Évalué à 1.
Le champs d'application est vaste et immédiat: Couler/immobiliser les serveurs de la concurrence, détourner l'attention, faire chié son monde etc ...
Premiere definition sur google:
http://dev4all.mtprod.com/articles.cgi?id=67&chapter=CHAPTER_CR(...)
>> Après si tu preferes qu'une faille reste dans la communauté black hat pendant 1 ans avant d'etre publique plutot que d'avoir une fenetre de 4 jours ou ta machine est vulnerable libre a toi.
Je ne parlais pas de ça. Quand on découvre une faille critique, on ne publie pas un exploit sur un site d'information, mais une note expliquant la nature du bug au développeur .
Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits, même pour le bien de la communauté . Et que tout les exploits sans aucune exception, hormis celui la, on les retrouve sur les sites de pirate.
La un patch a été publié dans l'urgence et au vue de la tronche du patch, ça montre que l'incidence du bug sur le reste du système n'avait meme pas été encore calculé.
[^] # Re: Bravo linux ...
Posté par ckyl . Évalué à 10.
C'est quoi le rapport avec la tambouille ? Tu crois que le maichant pirate payer par la maichante concurence attend que l'exploit soit publique pour aller le chercher sur /. ? C'est bizare mais j'ai un doute. Ce genre de personne a deja access a l'info ca ne change justement rien de ce cote. Y'a simplement les gamins qui effectivement vont un peu jouer c'est le seul parametre qui varie. C'est une faille locale ca limite l'impact. Si j'ai besoin de couler la concurence c'est pas sorcier de trouver quelqu'un avec les competences requises.
> Je ne parlais pas de ça. Quand on découvre une faille critique, on ne publie pas un exploit sur un site d'information, mais une note expliquant la nature du bug au développeur .
Encore une fois ca ne change rien hormis pour les gamins. Si dans ton adviso tu indiques le code fautif et le parametre fautif c'est qu'une question d'heures pour produire le code. Un mail a l'equipe interne leur laissant de corriger le problème c'est ideologiquement mieux certe. D'ailleur y'a un security@linux ? Le developpement bazar toussa c'est bien mais si je decouvre une faille j'envois mon message où ?
> Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits, même pour le bien de la communauté . Et que tout les exploits sans aucune exception, hormis celui la, on les retrouve sur les sites de pirate.
Mdr. Pour les motivations j'en sais rien et je m'en fou, ce n'est pas mon role que d'extrapoler les raisons pour lesquelles quelqu'un publie du code. (regarde le journal en dessous sur le pourquoi du vote blanc, c'est assez difficile de generaliser comme ca). Pour ce qui est des sites diffusants les exploits
http://k-otik.com/exploits/index.php(...)
je suis sur que se sont de mechant pirates terroristes qui se font chier a livrer une information en francais accessible au plus grand nombre.
D'ailleur securityfocus aussi c'est des pirates y'a tout les exploits postés sur bugtraq et vulndev d'archivé !
Essais d'etre credible 5 minutes.
Ici le mec a peu etre pas très bien géré ca arrive c'est pas la fin du monde non plus. Apres concretement, le bug est sur le bugzilla de gcc, un message a ete posté deux jours avant sur lklm (pas d'adresse de secu pour linux a ma connaissance donc le probleme est aussi du cote des devs). Qu'est ce que ca change que le code soit posté sur un site de news ? le code existe et est disponible ca change rien.
[^] # Re: Bravo linux ...
Posté par Code34 (site web personnel) . Évalué à -2.
Wow vomissures, et lieux communs
>>> Encore une fois ca ne change rien hormis pour les gamins. Si dans ton adviso tu indiques le code fautif et le parametre fautif c'est qu'une question d'heures pour produire le code.
T'es sérieux ?
>> Un mail a l'equipe interne leur laissant de corriger le problème c'est ideologiquement mieux certe. D'ailleur y'a un security@linux ? Le developpement bazar toussa c'est bien mais si je decouvre une faille j'envois mon message où ?
Ca semble logique, si tu tombes sur une faille dans le kernel linux, t envoies ton rapport à Microsoft.
>> Mdr. Pour les motivations j'en sais rien et je m'en fou, ce n'est pas mon role que d'extrapoler les raisons pour lesquelles quelqu'un publie du code.
On analyse pas les raisons, on analyse le code justement. Ce code fait crasher linux.
>> (regarde le journal en dessous sur le pourquoi du vote blanc, c'est assez difficile de generaliser comme ca).
Aucun rapport avec la politique
>> http://k-otik.com/exploits/index.php(...(...))
je suis sur que se sont de mechant pirates terroristes qui se font chier a livrer une information en francais accessible au plus grand nom
Oui c'est une erreur manifeste de leur part de publier un exploit, alors qu'il n a pas été corrigé.
>>Essais d'etre credible 5 minutes.
Difficile quand on discute avec toi.
>> Ici le mec a peu etre pas très bien géré ca arrive c'est pas la fin du monde non plus.
Non, il a juste rendu publique une faille de sécurité, ainsi que le programme rendant vulnérable la quasi totalité du parc informatique LINUX x86.
Ton indifférence est compréhensible, car tu n'as pas de connaissances suffisantes en matière de développement ou d'administration système .
Mais sache que si un jour tu commences à travailler dans des environnements avec des contraintes, on te soufflera dans ton oreillette que des parcs avec quelques milliers d'utilisateurs, ça ne se migrent pas du jour au lendemain avec un patch bancal .
De même tu comprendras que tu ne vas pas voir un client, et lui dire
"désolé, on a une centaine de serveurs sur le carreau parce qu'un neuneu a publié une faille critique sur un site d'info relayé mondialement . Il a publié cette faille, parce qu'il n'a pas trouvé un seul email valide pour prévenir les développeurs du kernel linux . Ensuite une dizaine de petits malins de votre boite se sont empressés de faire sauter les serveurs ."
"Cher client,
Ne vous inquietez pas . Depuis 3 jours, 100 de vos serveurs d'applications ont crashés rendant impossible le travail de vos 5000 employés . Il s'agissait en fait d'une faille de sécurité connue par quelques gamins, et qui a été publié pour le bonheur de la communauté open source sur un site internet, et utilisé par vos employés .
L'auteur de cet exploit l'a publié sur l'internet car il n'arrivait pas à trouver les emails des developpeurs du noyau Linux, c'était donc plus simple pour lui de rédiger un article sur un site de presse, pour que l'information soit relayé mondialement, et que dans les futures versions de linux ça soit corrigé.
D'ailleurs, le site de sécurité K-optik en France a publié aussi cet exploit, ce qui démontre que la personne l'ayant écrit, etait dénué d'intention, elle voulait juste ecrire du code pour du code.
Pour finir, nous avons l'honneur de vous annoncer que, Cykl de LINUXFR, nous confirme que ça n'est pas la fin du monde, et que vous pouvez donc dormir tranquille, vos moutons mourront bien gardé.
Cordialement,
."
Cette énorme bourde vaudra pour le monde linux, une superbe anti-publicité de Microsoft expliquant pourquoi l'Open source n'est pas sécurisé, et comment un type avec 10 lignes à mis en péril le parc informatique de plusieurs milliers d'entreprise sous linux.
[^] # Re: Bravo linux ...
Posté par ckyl . Évalué à 4.
Réalité mon pauvre.
>T'es sérieux ?
Tout en dépendant de la faille (y'en a des bien tordues) à partir du moment ou l'endroit est identifiée et la cause comprise le code n'est qu'une question d'heures ou de jours.
> Ca semble logique, si tu tombes sur une faille dans le kernel linux, t envoies ton rapport à Microsoft.
Tu fais expres de faire le boulet ? Tout les vendeurs ont un security@domaine qui est une adresse privée et seuls les interessées (la team securité) recoivent l'information ca permet justement d'éviter que trop d'info ne se balandent pour indiquer qu'une faille existe avant que ca soit patché. Il me semble que linux ne dispose pas d'une telle adresse; si pour signaler un probleme de sécu tu dois le poster sur lkml ca me parait un peu contradictoire avec ce que tu avances.
> On analyse pas les raisons, on analyse le code justement. Ce code fait crasher linux.
"Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits" tu appels ca analyser le code ?!? C'est une intepretation des faits d'autruit. Quand le mec a balance le code sur le bugzilla de gcc il n'avait pas forcement compris l'impact a partir de ce moment c'était trop tard. La lecon de l'exploit dans la VM linux n'a pas marqué les esprits apparement. Les "pirates" ne sont pas tous des guignols du dimanche qui vont sur 1337.c0m pour chopper les exploits, y'en a aussi qui codent pour des projets libres, qui suivent les changelogs, les bugzilla, qui lisent du code.
> Non, il a juste rendu publique une faille de sécurité, ainsi que le programme rendant vulnérable la quasi totalité du parc informatique LINUX x86.
C'est un fait.
> Ton indifférence est compréhensible, car tu n'as pas de connaissances suffisantes en matière de développement ou d'administration système .
Mouhaha je l'a bookmark celle la :-)
Ce n'est pas de l'indifference, c'est qu'a partir d'un moment tu es conscient que les failles n'existent pas qu'a partir du moment ou ./ en a parlé. Des failles noyaux y'en a une trippotée non divulgée ca en a toujours été ainsi. Tu as le choix entre un truc inconnu possedé par peu de personnes ou quelques chose de très répendu qui sera vite corrigé. Si ton entreprise est sensible je prefere de tres loin la seconde solution. Si tu es qu'une societe X ou Y alors effectivement il y a plus de risques de casse dans le second cas. C'est une faille locale, a partir du moment ou tu laisses quelqu'un faire un exec() il doit y avoir un minimum de confiance et de controle. L'utilisateur doit savoir qu'il sera puni en cas d'abus les autres ne devraient pas acceder a la machine.
"Ensuite une dizaine de petits malins de votre boite se sont empressés de faire sauter les serveurs ."
Faute grave, licenciement, tribunal (godfrain/LSI). Tes employes peuvent foutre le feux aux locaux, ou voler le matos informatique. Ils ne le font pas soit pas ce que ce ne sont pas des crétins soit par ce qu'ils en connaissent les conséquences. En informatique il en va de même.
Ce n'est ni la premiere ni la derniere faille, il y en aura toujours certaines publiques, certaines privees les conséquences variant selon la sensibilité de ce à quoi sert le parc. Si tu n'arrives pas a dormir avec cette idée et cette gestion du risque change de métier. Je te signal qu'au moins 3 codes pour l'exploit de la VM ont été publiés très rapidement et qu'au moins un était fonctionel presque tel quel...
[^] # Re: Bravo linux ...
Posté par Guillaume Knispel . Évalué à 5.
[^] # Re: Bravo linux ...
Posté par ckyl . Évalué à 2.
FreeBSD : possibilité de modifier les tables de routage depuis une jail()
NetBSD : There exists a integer handling vulnerability in NetBSD swapctl(2) system call. It seems that this vulnerability can not be exploited to gain super-user privilegies, but any local attacker can crash the kernel. The vulnerability has been discovered several months ago by Evgeny Demidov during NetBSD kernel source code au dit. It has been made availabe to VulnDisco clients two months ago.
IRIX : that under certain conditions non privileged users can use the syssgi system call SGI_IOPROBE to read and write kernel memory which can be used to obtain root user privileges.
Two local DoS fixes are also addressed in these patches
# J'ai testé...
Posté par Florent Bayle (site web personnel) . Évalué à 8.
Quelques remarques :
- on a beau être prévenu, c'est vraiment surprenant... Chez moi, j'était en graphique, l'écran s'est figé, et pouf, plus moyen de faire quoi que ce soit. J'ai testé quasiment toutes les combinaisons de touches que je connaissait, rien, même les "magic sys keys" ne font rien du tout...
- il y a tout de même quelques warnings à la compilation :
florent@pluton:/tmp$ gcc test.c
test.c: In function `Handler':
test.c:8: warning: use of memory input without lvalue in asm operand 0 is deprecated
test.c:10: warning: use of memory input without lvalue in asm operand 0 is deprecated
Voilà, si vous voulez vous aussi tester, je vous déconseile de le faire sur le linux que vous utilisez habituellement, prenez plutôt un live cd, ou testez chez votre voisin (euh... quoi que je sait pas si c'est recommandé...).
[^] # Re: J'ai testé...
Posté par glb . Évalué à 1.
Ta machine est tout à fait en mesure de se prendre un reset dans la face, sans trop de soucis, voire aucun...
après le http://www.chezmoicamarche.org(...) , chuis surpris que personne n'ait encore déposé le nom de domaine chezmoicaplante.org (encore disponible) avec le code en première page ^_^
[^] # Re: J'ai testé...
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: J'ai testé...
Posté par ckyl . Évalué à 3.
Ca serait rigolo comme warning tiens. Je vais soumettre un patch a gcc :-)
</>
# TCC
Posté par dlfpbot . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.