lundi 05 janvier

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

Exploit et explications (3276 hits)
Patch 2.4.2x (83618 hits)
Patch 2.6.x (84224 hits)
Patch 2.6.x_64 (84038 hits)

Dépêche modérée par

Oumph
rootix

Articles : Vulnérabilité de tous les noyaux 2.4.x / 2.6.x

Posté par FRLinux (page perso, ). Modéré le 15 juin 2004.

Une nouvelle vulnérabilité a été découverte le 09 juin 2004 concernant tous les noyaux 2.4.x et 2.6.x (détails des noyaux non vulnérables dans l'annonce en anglais).

Cette faille nécessite un accès local à la machine et peut s'exécuter par la compilation d'un simple programme en C. Le bug a été également reporté dans le bugzilla de GCC (versions affectées 2.96, 3.0, 3.1, 3.2, 3.3 et 3.3.2).

Le patch concerne un simple changement de ligne sur la fonction clear_fpu() changeant l'appel asm volatile de ("fwait") vers ("fnclex ; fwait").

Le lien comporte un patch pour 2.4.x, 2.6.x et le test permettant de tester votre système, il est recommandé de synchroniser les systèmes de fichiers avant de tenter l'exploit.

Exploit et explications (3276 hits)
Patch 2.4.2x (83618 hits)
Patch 2.6.x (84224 hits)
Patch 2.6.x_64 (84038 hits)

> Lire les commentaires (40 commentaires, moyenne: 2,6).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Le patch ne suffit pas

Posté par capicapio () le 15/06/2004 à 08:46. (lien). Évalué à 11.

"Evil can not do any damange once this patch is applied, but it will keep running at 99% CPU until it is killed (like any other process)."

En gros, le code malfaisant ne peut plus endommager votre système une fois que vous avez appliqué le patch (et recompilé le noyau), mais l'application tournera, occupant 99% du CPU jusqu'à ce que vous la tuiez.

Moralité : comme toujours, patch ou pas, faille ou pas, ayez toujours un oeil sur votre système!

[^]Re: Le patch ne suffit pas

Posté par free2.org (page perso, ) le 15/06/2004 à 08:53. (lien). Évalué à 7.
tu as oublié le " like any other process"
Car oui, quelqu'un qui peut lancer des process sur ta machine peut toujours la ralentir (sauf si tu utilises ulimit, donc pas besoin de nouveau patch pour ce type de probleme déjà bien connu)

help ulimit
- [^]Re: Le patch ne suffit pas
  
  Posté par free2.org (page perso, ) le 15/06/2004 à 09:03. (lien). Évalué à 2.
  pardon, il vaut mieux faire quand on est root:
  man setrlimit
  http://www.die.net/doc/linux/man/man2/setrlimit.2.html(...)
  
  car ces limites ne peuvent plus etre augmentées par un utilisateur ensuite
- [+] [^]Re: Le patch ne suffit pas
  
  Posté par capicapio () le 15/06/2004 à 09:03. (lien). Évalué à -1.
  Nous sommes d'accord : ce que je veux dire c'est que, faille ou pas, quelqu'un pouvant lancer un processus quelconque peut poser un problème (éventuellement, sans mauvaise intention).
  - [^]Re: Le patch ne suffit pas
    
    Posté par gc (page perso, ) le 15/06/2004 à 09:38. (lien). Évalué à 2.
    Alors avoue que ton titre "le patch ne suffit pas" n'était pas spécialement bien trouvé..
- [^]Re: Le patch ne suffit pas
  
  Posté par Matthieu C () le 15/06/2004 à 10:45. (lien). Évalué à 2.
  suaf que ulimit est totalement inutile des que tu veux offrir une connection graphique (cf http://linuxfr.org/comments/429463,1.html(...))
  
  En effet la limite memoire ce faire par process et non par par user, et pour les connexions graphiques il faut entre 50-100Mo par process (mozilla, OOO) et au moins une 20 process, donc au total un utilisateur pourra allouer 1 a 2 Go de memoire...
  
  Donc un petit programme a base de malloc de et fork peut faire pas mal de degat (si mes souvenir sont bon quand le kernel manque de memoire, il tue des process aleatoirement, par contre je sais plus si ceux en root son protege...)...
  - [+] [^]Re: Le patch ne suffit pas
    
    Posté par thaodalf () le 15/06/2004 à 10:48. (lien). Évalué à -1.
    c'est pour ca que linux peut gerer 64 tera de ram !
    
    --> []
  - [^]Re: Le patch ne suffit pas
    
    Posté par Wajsberg Julien () le 16/06/2004 à 07:54. (lien). Évalué à 1.
    Jusqu'au 2.4.26, linux utilisait le OOM (Out Of Mémory)- killer, qui essayait de trouver le "bon" process à killer. Ca a été assez décrié, car dans certains cas, il killait des "mauvais" processus...
    
    Depuis, c'est une option de config désactivée par défaut, le comportement par défaut étant de killer l'appli qui est demandeuse de mémoire au moment où il n'y en a plus.
    
    Ceci dit, c'est du hors-sujet, on parle pas du tout de mémoire ici normalement :)
    - [^]Re: Le patch ne suffit pas
      
      Posté par cykl (Jabber id, ) le 16/06/2004 à 08:01. (lien). Évalué à 3.
      En même temps si ton but est de nuire tu malloc() pas comme un débile tu t'arretes juste avant d'épuiser la quantité RAM + swap. Du coup sur les noyaux sans OOM-killer la charge va s'envoler et la machine devient souvent irrecuperable, et sur les nouyaux avec alors il va tuer les process demarrant.
      
      Le problème c'est que dans les solutions offertes actuellement et accessible par le plus grand nombre tu as le choix entre ne rien permettre a l'utilisateur (restrictions tres forte) ou alors lui permettre le DoS.

FEDORA CORE 2 USER

Posté par rsystem () le 15/06/2004 à 08:47. (lien). Évalué à 4.

pour ceux qui comme moi utilisent la fedora Core 2,
le kernel 2.6.6-1.435 est à jour et disponible depuis hier soir.

messieurs à vos compilo

N.B: le kernel source code pour le 2.6.6-1.435 n'était pas disponible sur le mirroir de rpmfind.

y'a pas à dire yum est tous simplement génial ;)

[^]Re: FEDORA CORE 2 USER

Posté par Shadow_Mind () le 15/06/2004 à 08:53. (lien). Évalué à 4.
Le paquetage kernel-source-2.6.6-1.435 est disponible à ces endroits :

http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/i(...)
http://mirrors.kernel.org/fedora/core/updates/2/i386/(...)

Le .src.rpm de ce noyau est disponible à ces endroits :

http://download.fedora.redhat.com/pub/fedora/linux/core/updates/2/i(...)
http://mirrors.kernel.org/fedora/core/updates/2/i386/SRPMS/(...)

Je l'indique pour les personnes voulant récuperer le paquetage à la main (pour diverses raisons).

[^]Re: FEDORA CORE 2 USER

Posté par 007 () le 15/06/2004 à 11:25. (lien). Évalué à 1.
Le .spec est intéressant. Il support maintenant ppc. Déjà que portage de FC vers sparc est pratiquement terminé (manque les isos seulement), il y aura peut-être un portage vers ppc.

Comment découvre-t-on de telles failles ?

Posté par Salagnac () le 15/06/2004 à 08:48. (lien). Évalué à 7.

Comment découvre-t-on de telles failles ? C'est une question que je me suis toujours posée lorsque sont rendues publiques des failles aussi tordues ?
"discovered by Stian Skjelstad while he was doing some code tests.", dit le premier lien. Mais qu'essayait-il de tester ?

Ca me laisse quand meme perplexe, surtout que, le gars qui a découvert ça, il n'était pas à priori mal intentionné, mais ensuite, une fois la nouvelle répandue, plein de script kiddies ont fait tomber des serveurs honnètes. (non, je ne suis pas en train de relancer le troll sur la non-divulgation des failles)

[^]Re: Comment découvre-t-on de telles failles ?

Posté par _PinG _ () le 15/06/2004 à 08:57. (lien). Évalué à 5.
Bah on peut auditer certaines parties sensibles, on peut rechercher certains modèles ou fonctions connues pour poser des problèmes et regarder si tout à été prévu, on peut aussi tomber par hasard sur une faille.

On code un truc, on se trompe (oui oui, ca arrive :D ), et le comportement deviens bizare (core dump d'un daemon, blocage système, code de retour de la fonction système bizare...). Alors on fouille pour trouver d'où cela viens.

Il y a trop de moyen de tomber sur une faille pour les ennumérer de facon exhaustive...
- [^]Re: Comment découvre-t-on de telles failles ?
  
  Posté par petit_bibi () le 15/06/2004 à 16:14. (lien). Évalué à 4.
  ou core dump de bash quand on lui fait faire:
  eval 'toto=('
  
  J' ai découvert ça par hasard pendant l' écriture d' une librairie bash (oui oui j' ai bien dit bash ...)
  Je ne sais pas si ça peut être exploité à des fins néfastes mais un collègue à eu la gentillesse de soumettre le rapport de bug pour moi.

[^]Re: Comment découvre-t-on de telles failles ?

Posté par FRLinux (page perso, ) le 15/06/2004 à 08:57. (lien). Évalué à 5.
Ben comme l'indique le premier lien, le développeur l'a découverte par hasard alors qu'il était en train de tester du code qu'il venait de compiler. Donc généralement, soit par hasard, soit en optimisant du code.

Steph
- [^]Re: Comment découvre-t-on de telles failles ?
  
  Posté par syj () le 15/06/2004 à 09:12. (lien). Évalué à 3.
  Et son code peut paraître tordu vu qu'il l'a peut être simplifié au maximum pour cerner que la partie de code incriminer.
  La cause du problème aurait été peut être trouvé moin rapidement
  si il avait publier sous la forme d'un programme faisant plusieurs Ko ou Mo.

[+] [^]Re: Comment découvre-t-on de telles failles ?

Posté par Dafatfab () le 15/06/2004 à 08:59. (lien). Évalué à -2.
Ce qui fait la difference entre un bon admin et un mauvais admin....:-)
(please no troll)

Bon apres, faut avoir un acces local pour cette faille....

Explications

Posté par Christophe Lucas (page perso, ) le 15/06/2004 à 09:21. (lien). Évalué à 7.

Pour ceux que cela intéresse et veulent savoir pourquoi le noyau freeze, lisez ce mail dans le thread pointé par le journal ( https://linuxfr.org/~ange_thom/13734.html(...) ) :
http://marc.theaimsgroup.com/?l=linux-kernel&m=108704809114434&(...)

Ok, le patch du mec est un peu light ;-)

Bonne journée.
--
Christophe

--
- Christophe -

Crash et non root access

Posté par gc (page perso, ) le 15/06/2004 à 09:52. (lien). Évalué à 5.

Moi quand je lis "vulnérabilité" je pense tout de suite à "méchant hacker^Hcracker qui a accès root à une machine sans y être normalement autorisé". Je suis le seul ou non ?

Bref, une vulnérabilité qui crash le kernel saipabien(tm) mais c'est quand même largement moins grave qu'un root access.

D'ailleurs c'est amusant, chez d'autres OS propriétaires il y a plusieurs vulnérabilités par an qui donne un root access, sous linux c'est quand même pas si souvent (le bug ptrace est déjà vieux... date des alentours du 2.4.20 IIRC).

[^]Re: Crash et non root access

Posté par Jean Parpaillon (Jabber id, page perso, ) le 15/06/2004 à 10:03. (lien). Évalué à 3.
Sur un serveur en production avec 10000 utilisateurs, ça peut être embêtant de devoir rebooter une machine...
- [^]Re: Crash et non root access
  
  Posté par Christophe Lucas (page perso, ) le 15/06/2004 à 10:07. (lien). Évalué à 1.
  Je ne suis pas sûr que ce soit 100% sûr , mais bon il suffirait en théorie d'utiliser le patch "kexec" pour ne pas rebooter ;-) , mais pour l'instant attention à la casse.
  
  Quelqu'un a une expérience sur l'utilisation de kexec ??
  
  http://www-106.ibm.com/developerworks/linux/library/l-kexec.html(...)
  http://developer.osdl.org/rddunlap/kexec/(...)
  
  Bonne journée.
  --
  Christophe.
  
  --
  - Christophe -
  - [^]Re: Crash et non root access
    
    Posté par tinodeleste () le 15/06/2004 à 12:25. (lien). Évalué à 6.
    k-exec, ca évite le reboot hard (détection des matériels Scsi, raid...) mais pas le reboot soft, ca permet juste de tester son nouveau noyau plus vite. (presque tout les process sont tués, et donc, pour les 10000 utilisateurs, il y a perte du service)
- [^]Re: Crash et non root access
  
  Posté par 007 () le 15/06/2004 à 10:31. (lien). Évalué à 1.
  > Sur un serveur en production avec 10000 utilisateurs
  
  Il faut un accès ssh. Dans 99 % des cas, les serveurs ont un accès ssh uniquement pour les personnes de confiance.
  - [^]Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?
    
    Posté par dvrasp (page perso, ) le 15/06/2004 à 12:10. (lien). Évalué à 4.
    C'est sans compter, par exemple, sur un script php mal sécurisé, qui permettrait d'exécuter des commandes shell (donc uploader et exécuter un programme dans /tmp). Le safe-mode n'est pas toujours pratiquable, selon les applications.
    Ça peut aussi être un service non privilégié, mais vulnérable. Même dans un chroot très restrictif, on peut exploiter ce bug kernel directement dans un shellcode.
    Il ne faut pas minimiser l'importance d'une vulnérabilité parce qu'elle n'est exploitable qu'en « local ».
    - [^]Re: Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?
      
      Posté par 007 () le 15/06/2004 à 13:09. (lien). Évalué à 1.
      Tous les trous de sécurité doivent être pris au sérieux. C'est une question de principe. Mais il faut relativer. A distance pour exploiter ce trou de sécurité il faut déjà un autre très gros trou de sécurité qui permet d'exécuter n'importe quel programme sur la machine distante. Donc...
    - [^]Re: Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?
      
      Posté par 007 () le 15/06/2004 à 13:11. (lien). Évalué à 1.
      btw : même si tu n'es pas en "safe mode" ça veux dire qu'il y a un system() ou exec() qui traine dans ton code php qui peut exécuter n'importe quelle commande. T'as un gros trou de sécurité à corriger :-)
  - [^]Re: Crash et non root access
    
    Posté par Matthieu Moy (page perso, ) le 16/06/2004 à 09:59. (lien). Évalué à 4.
    > Il faut un accès ssh. Dans 99 % des cas, les serveurs ont un accès ssh uniquement pour les personnes de confiance.
    
    C'est ce que pensaient les admins de ftp.gnu.org en ne patchant pas leur noyau. "Naaan, c'est pas grave, c'est qu'une faille locale ..."
    - [^]Re: Crash et non root access
      
      Posté par 007 () le 16/06/2004 à 13:10. (lien). Évalué à 0.
      Attention, je vais démontrer que je suis super intelligent :
      - Ce n'est pas parce que ça arrive rarement que ça n'arrive jamais
      
      Fichtre. Trop fort je suis.
      
      Sinon j'ai parlé de "personnes de confiance".
      Si finalement ce ne sont pas des "personnes de confiance"...
      
      Puis je ne dis pas qu'il faut rien faire. D'ailleur sur ma bécane où il n'y a que moi comme utilisateur, c'est corrigé. Comme je le dis ailleur, la sécurité c'est une question de principe. Mais ce n'est pas une raison pour affoler les foules dès que le noyau à le hoquet car il a avaler un patch de travers et sortir le plan ORSEC et appeler le GIGN.
      
      On est pas aussi --- que G. Bush ?
      "Il faut raison garder" comme on dit dans la vieille Europe.
    - [^]Re: Crash et non root access
      
      Posté par gnap gnap (page perso, ) le 21/06/2004 à 16:43. (lien). Évalué à 1.
      Le problème qu'ils ont, c'est qu'ils croient qu'il suffit de couper l'accès à tout le monde pour être en sécurité. Apparement ce ne fut pas efficace pour ftp.gnu.org mais cette logique est maintenant appliqué sur toutes les machines de GNU.
      Le problème, c'est que ça ne donne plus aux bonnes volontés l'opportunité de trouver et régler des failles, ça met tout entre les mains des sysadmins employés de la FSF USA (une seule personne jusqu'en novembre 2003, deux depuis) qui sont, de manière notoire, tout le temps surchargé de boulot.
- [^]Re: Crash et non root access
  
  Posté par ArBaDaCarBa () le 15/06/2004 à 13:35. (lien). Évalué à 2.
  > Sur un serveur en production avec 10000 utilisateurs, ça peut être embêtant de devoir rebooter une machine...
  
  Certainement... Ça va donc être très dur d'installer un nouveau kernel, non ? ;)
  - [^]Re: Crash et non root access
    
    Posté par Fabien Renaud () le 15/06/2004 à 14:49. (lien). Évalué à 1.
    En general quand tu as 10.000 utilisateurs sur un serveur tu en as un de secours. enfin c´est quand meme la moindre des choses

[^]Re: Crash et non root access

Posté par ouah (page perso, ) le 16/06/2004 à 06:41. (lien). Évalué à 0.
> D'ailleurs c'est amusant, chez d'autres OS propriétaires il y a
> plusieurs vulnérabilités par an qui donne un root access, sous
> linux c'est quand même pas si souvent (le bug ptrace est déjà > vieux... date des alentours du 2.4.20 IIRC).

c'est beau de rêver.

Si on prend seulement les adviso de isec.pl durant la période janvier à avril de cette années, on a arrive à 4 local root sur le kernel Linux. C'est peu glorieux et aucun autre kernel n'a eu un aussi piètre palmarès durant la même période.

A décharge de Linux toutefois, si les autres OS profitaient de la même attention des hackers, il y aurait certainement autant de bug de sécurité de leur côté.
- [^]Re: Crash et non root access
  
  Posté par 007 () le 16/06/2004 à 09:25. (lien). Évalué à 2.
  > A décharge de Linux toutefois, si les autres OS profitaient de la même attention des hackers, il y aurait certainement autant de bug de sécurité de leur côté.
  
  Ajoutons que parmis les noyaux "open source", Linux est le plus complexe et aussi celui qui évolue le plus. Pour comparaison OpenBSD vient d'introduire SMP alors que c'est dans Linux depuis le 2.0.
  Même si tout n'est pas parfait, on n'a pas vraiment à se plaindre côté sécurité.

[+] Trollons...

Posté par Xavier Teyssier (Jabber id, page perso, ) le 15/06/2004 à 11:20. (lien). Évalué à -5.

Encore un bug/faille qui nous pousse à patcher le noyeau !

C'est nul ce système !

BSD, c'est Mieux !

:-)

[^]Re: Trollons...

Posté par cykl (Jabber id, ) le 15/06/2004 à 11:27. (lien). Évalué à 7.
Ratai !

Name: NetBSD kernel swapctl(2) vulnerability
Date: 11 June 2004
CVE candidate: not assigned
Author: Evgeny Demidov

Description:

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.
- [+] [^]Re: Trollons...
  
  Posté par Xavier Teyssier (Jabber id, page perso, ) le 15/06/2004 à 12:02. (lien). Évalué à -1.
  Oui mais non. NetBSD, c'est intéressant juste pour mettre un Unix dans sa cafetière. En parlant BSD, je pensais au seul OS qui soit vraiment sûr : OpenBSD ;-)
  
  (Comment ça, je vais me faire taper ? !)
  - [^]Re: Trollons...
    
    Posté par gc (page perso, ) le 15/06/2004 à 12:07. (lien). Évalué à 5.
    C'est clair qu'il doit pas être vulnérable vu que dans sa version par défaut (ce que tous les BSDistes utilisent comme "version de référence" puisque la plus secure) il n'y a pas de serveur ssh donc pas de login possible.
    - [^]Re: Trollons...
      
      Posté par Krunch (Jabber id, page perso, ) le 18/06/2004 à 18:47. (lien). Évalué à 2.
      
      il n'y a pas de serveur ssh donc pas de login possible
      Il me semble bien que si.
      
      --
      Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
      pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

Pile TCP/IP

Posté par Benjamin G. ( Prae ) (page perso, ) le 18/06/2004 à 09:59. (lien). Évalué à 1.

A noter que même après un freeze, le kernel continue de fonctionner de faire transiter les paquets ...

La pile réseau du kernel ne semble pas être affecté (allez savoir pourquoi ?!)

Si cela arrive sur un FW, cela ne pose pas de problème et permet de refaire une machine proprement sans se presser.

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Articles : Vulnérabilité de tous les noyaux 2.4.x / 2.6.x

Le patch ne suffit pas

[^]Re: Le patch ne suffit pas

[^]Re: Le patch ne suffit pas

[+] [^]Re: Le patch ne suffit pas

[^]Re: Le patch ne suffit pas

[^]Re: Le patch ne suffit pas

[+] [^]Re: Le patch ne suffit pas

[^]Re: Le patch ne suffit pas

[^]Re: Le patch ne suffit pas

FEDORA CORE 2 USER

[^]Re: FEDORA CORE 2 USER

[^]Re: FEDORA CORE 2 USER

Comment découvre-t-on de telles failles ?

[^]Re: Comment découvre-t-on de telles failles ?

[^]Re: Comment découvre-t-on de telles failles ?

[^]Re: Comment découvre-t-on de telles failles ?

[^]Re: Comment découvre-t-on de telles failles ?

[+] [^]Re: Comment découvre-t-on de telles failles ?

Explications

Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?

[^]Re: Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?

[^]Re: Accès SSH ? Ou seulement la possibilité d'exécuter un programme ?

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[^]Re: Crash et non root access

[+] Trollons...

[^]Re: Trollons...

[+] [^]Re: Trollons...

[^]Re: Trollons...

[^]Re: Trollons...

Pile TCP/IP