OpenWall Project patch pour 2.2.18 disponible

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
15
déc.
2000
Sécurité
Juste pour signaler que le patch openwall pour le noyau 2.2.18 est sorti. Comme d'habitude :
- la pile est non exécutable, ce qui limite les risques de buffer overflows ;
- des restrictions sur les liens dans /tmp (cool avec les récents problèmes de csh et bash) et les FIFOs
- limitations sur le /proc
- protection des file descriptors 0, 1, 2 pour les programmes SUID/SGID
...

[Note du modérateur : ce patch est utilisé pour augmenter la sécurité du noyau]

Aller plus loin

  • # à quand la modération du modérateur

    Posté par  . Évalué à 0.

    « Note du modérateur : se patch est »

    SE patch... hu hu

  • # l'auteur et le modérateur

    Posté par  (site web personnel) . Évalué à 1.

    note de l'auteur :
    l'auteur n'est en rien responsable des fautes d'orthographe du modérateur ... il a déja assez à faire avec les siennes ;-)

  • # Problèmes ?

    Posté par  (site web personnel) . Évalué à 1.

    Apparemment ce n'est pas parfait et/ou compatible avec l'existant, sinon le patch serait déjà incorporé au noyau officiel. Si quelqu'un l'utilisant pouvait nous faire un topo sur les problèmes potentiels, ça serait cool.

    • [^] # Re: Problèmes ?

      Posté par  . Évalué à 0.

      oui c'est cet idiot de linus qui ne veut pas l'in
      corporer parce qu'il dit que ca protege pas contre
      tous les buffer overflow .. je trouve que masquer
      les process des autres est normal, on ne vois pas
      les fichiers des autres, pourquoi les process ...

      • [^] # Re: Problèmes ?

        Posté par  . Évalué à 1.

        Il ne veut pas l'incorporer parce qu'il est perfectionniste, et ne veut pas patcher le système pour corriger les erreurs des autres. Ces patchs ne rendent pas le système plus résistant d'après Linus, sa position n'est pas stupide.

        L'exemple de la pile exécutable a été discuté plusieurs fois, et oblige simplement les buffer-overrun a changer de mécanisme, les rendant simplement légèrement plus complexe à écrire.

        Si cette modification est ajouté au noyau, alors tous les noyaux en profiterons, et toutes les attaques seronts alors systématiquement modifiées pour prendre cela en compte, unique conséquence: le noyau est plus complexe.

        • [^] # Re: Problèmes ?

          Posté par  . Évalué à 0.

          oui surtout que coller ton code a executer ailleur que sur la pile est vraiment pas plus compiqué.
          Juste différent. Conclusion rendre la pile non-executable est pas idiot, mais ne protege pas des buffer-overflow du tout.
          Linus est pas si con que ca ...

          • [^] # Re: Problèmes ?

            Posté par  . Évalué à 0.

            Une attaque a distance est nettement plus
            difficile sur une box openwallee . Il est
            impossible de faire des return into libc car celle ci est loadee a une adresse virtuelle contenant
            un 0x00 .

            Il est autrement possible de bypasser ce patch en local en retournant dans la procedure linkage table . EN remote, ca me parait extremement difficile . En remote il est possible de retourner dans un chunk malloque mais l'adresse des buffer alloues dynamiquement change considerablement selon les machines, contrairement aux adresses des buffers locaux qui sont tout le temps les memes a quelques centaines d'octets pret selon la taille de l'environnement .

            Personnelement, je trouve que openwall rends l'exploitation a distance extrement difficile, mais je loupe peutt etre quelquechose ... ?

            Reponses directement a :
            vanegu_j@epita.fr

        • [^] # Re: Problèmes ?

          Posté par  (site web personnel) . Évalué à 1.

          > L'exemple de la pile exécutable a été discuté
          > plusieurs fois, et oblige simplement les
          > buffer-overrun a changer de mécanisme, les
          > rendant simplement légèrement plus complexe à
          > écrire.

          Dans le fond, je suis plutôt d'accord ... mais est-ce qu'augmenter la difficulté des attaques ne diminue le nombre de personnes susceptibles de les employer/utiliser/inventer ? Je crois que oui.

          Selon moi, mon propre avis, mon opinion qui n'engage que moi, plus tu as de lignes de défenses, moins de personnes pourront (au sens de "seront capables") de s'en prendre à toi.

          Le débat est ouvert ...

          • [^] # Re: Problèmes ?

            Posté par  . Évalué à 0.

            ça va peut être réduire le nombre de personnes capable de concevoir une attaque, mais ceux qui les conçoivent ne sont pas ceux qui les utilisent. Je pense que le script-kiddie de base n'a qu'une notion très vague de ce qu'est un buffer-overflow...

        • [^] # Re: Problèmes ?

          Posté par  . Évalué à 0.

          Au LSM de bordeau, on avait pu entendre Linda Walsh de SGI nous parler de Trix (Irix plus Secure) ainsi que du developpement qu'ils menaient sur Linux pour offrir des fonctionnalités comparable à Trix en matière de contre aux attacks du type Buffer Overflow.
          Quelqu'un a t'il des infos plus récentes sur ce projet?

    • [^] # Re: Problèmes ?

      Posté par  (site web personnel) . Évalué à 1.

      j'utilise ce patch depuis pas mal de temps maintenant :
      CONFIG_SECURE_STACK=y
      CONFIG_SECURE_STACK_SMART=y
      CONFIG_SECURE_LINK=y
      CONFIG_SECURE_FIFO=y
      # CONFIG_SECURE_PROC is not set
      CONFIG_SECURE_FD_0_1_2=y
      # CONFIG_SECURE_RLIMIT_NPROC is not set
      # CONFIG_SECURE_SHM is not set

      Et je n'ai jamais rencontré de problème ... sauf quand je veux faire des tests avec des bo ou des liens foireux dans /tmp ;-) Du coup, je les fait sur une autre machine.

  • # Aucun rapport mais

    Posté par  (site web personnel) . Évalué à 1.

    Sur http://linuxfr.org/info/(...) ,

    "malgré que" ? Je ne me rappelle jamais si cela se dit ou non.

    D'autre part, "100mbits" (lire 100 milli-bits) devrait être "100Mbit/s" (lire 100 Mega-bits par second).

    Voilà c'était un commentaire inintéressant à scorer -1.

    • [^] # Re: Aucun rapport mais

      Posté par  . Évalué à 0.

      Malgré que est complètement correct. C'est d'ailleurs une question du Trivial Pursuit.

      • [^] # Re: Aucun rapport mais

        Posté par  . Évalué à 0.

        Trivial poursuit n'est pas forcement une référence.


        On peut dire « Malgré le fait que »...

  • # LIDS + Openwall

    Posté par  . Évalué à 1.

    Les personnes interesses par Openwall seront sans doutes egalement interessees par LIDS. Le probleme est que les 2 patches appliques conjointement proviquent des erreurs. Il faut plutrot appliquer le patch special Openwal + LIDS, qu'on peut trouver ici (2.2.17 only pour le moment).

    http://root-it.be/community/lids/(...)

    Attention, LIDS est beaucoup plus chiant a configurer que Openwall, lisez *bien* la doc avant de rebooter avec le noyau patche.

    Rappelons egalement qu'appliquer un patch au kernel peut donner une fausse impression de securite et qu'il y a bien d'autres choses a faire en priorite, avant d'en venir a patcher le noyau (fermer les ports, virer les SUID root etc)...

    • [^] # Re: LIDS + Openwall

      Posté par  (site web personnel) . Évalué à 1.

      <commentaire utile>
      entièrement d'accord avec ta dernière phrase :)
      </commentaire utile>
      Et le prire, c'est que je n'ai rien d'autre à ajouter ...

      • [^] # Re: LIDS + Openwall

        Posté par  . Évalué à 1.

        J'en profite pour faire de la pub pour le patch Low Latency. Je viens de le mettre en place sur mon noyau 2.4.0-test12. C'est vraiment terrible.

  • # process

    Posté par  . Évalué à 0.

    une fonction qui n'as rien a voir avec la securité
    mais plutot privacité est de masquer les process
    des autres, ca me parais une bonne chose

    • [^] # Re: process

      Posté par  . Évalué à 1.

      privacité ? C'est vrai, il était tard ;)

      Sur le fond, ça dépend. En effet, parfois on ne veut voir que ses process (mais c'est déjà possible), parfois on tient à savoir pourquoi cette sal***rie de machine rame de cette façon, sans pour autant aller emmerder l'admin système. Par exemple, si X a pris de l'embonpoint, tu le sais tout de suite et tu contactes l'admin. Ca peut être pratique (sauf pour l'admin qui surfes sur Linuxfr ;)

Suivre le flux des commentaires

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