Faille majeure dans Ipfilter

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
9
avr.
2001
Sécurité
IPFilter, qui est aux *BSD ce que IPChains est à Linux (mais en beaucoup plus puissant), comporte une faille dans la gestion des paquets fragmentés.

Par exemple, si le Firewall autorise les connexion vers le port 80 d'un serveur web dans une DMZ, l'exploitation de cette faille permet de se connecter à TOUS les ports ouverts sur cette machine, outrepassant les règles du firewall.

Les détails sont dans un post de Bugtraq, et la version 3.4.17 d'IPFilter corrige ce problème.

Aller plus loin

  • # exploit ?

    Posté par  . Évalué à 0.

    si le Firewall autorise les connexion vers le port 80 d'un serveur web dans une DMZ, l'exploitation de cette faille permet de se connecter à TOUS les ports ouverts sur cette machine

    Pas forcément. Le match de fragement a eu lieu APRES la vérification de srcip+dstip+ip#. Donc à condition qu'une connexion soit établit.

    De l'avis de Darren :

    How to exploit? Something will end up on bugtraq but so far, what I've seen isn't a complete exploit of the problem.

    Il s'agit d'un bug, mais pas encore d'exploit, il nous laisse donc le temps de patcher le kernel ;-)
    • [^] # Re: exploit ?

      Posté par  . Évalué à 0.

      A ce que j'ai compris, voici comment ça se passe un peu plus précisément:
      - un client envoie un premier fragment de paquet IP vers le fw sur un port autorisé par IPFilter
      - a partir de là, le client peut contacter n'importe quel port normalement interdit du fw, moyennant une petite bidouille dans l'entête des paquets envoyés
      - ceci n'est valable que pendant un certain temps donc il faut continuer a envoyer des fragments de paquet IP (il faut que IPFilter soit en attente de fragments pour que l'exploit soit possible)

      Ce n'est pas bien dur à exploiter! <anti-troll>je ne dis pas non plus que c'est facile à exploiter</anti-troll>

      pas encore d'exploit
      Heu, quand je lis la bugtraq, je vois:

      These are the - intentionally slightly broken - diffs to be applied to fragrouter 1.6 to implement the described attack.

      L'exploit existe, il faut juste se creuser les méninges pour le faire marcher...
      • [^] # Re: exploit ?

        Posté par  . Évalué à 0.

        T'a pas tout lu :
        déjà un paquet IP sa se fragmente pas ! (c'est un protocole non connecté)

        En gros, il faut fragmenter un paquet TCP en au moins 3 morceaux : tu envoie le premier qui met la machine à états en mode "passant" pour les autres

        tu envoie un autre fragment qui ne soit pas le 2ème, la machine à état va se mettre en mode "je laisse passer tous les paquets de cette connexion"
        et là tu fait passer les paquets merdiques en faisant croire qu'il sont de la même connexion (voir bugtraq pour la definition).

        si tu avais passé tous les fragments dans le bon ordre, au passage du dernier la machine a états aurait viré la porte de cette connexion et donc pas moyen de passer des merdes.


        En résumé, c'est le passage d'un fragment dans le désordre qui provoque le passage en mode "robinet ouvert".

        Les attaque nécessitent sont donc un peu (pas beaucoup) hazardeuses.

        La morale essaie pas de fragmenter un paquet IP !
  • # News BSD / Troll

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

    Enfin une new *BSD qui fait plaisir :)
    • [^] # Re: News BSD / Troll

      Posté par  . Évalué à -1.

      Dit le Linuxien crétin et statisfait. Pour te remettre à ta place je vais te quoter une portion du programme avec lequel le problème a été mis en évidence:

      *** 126,132 ****
      NULL, /* ATTACK_MISC */
      "misc-1: Windows NT 4 SP2 - http://www.dataprotect.com/ntfrag/",(...)
      "misc-2: Linux IP chains - http://www.dataprotect.com/ipchains/(...) ",
      ! NULL,
      NULL,
      NULL,

      C'est cool, l'URL qui va bien est dedans...

      Enfin pour en finir je te suggère d'aller voir les stats sur les advisories de sécurité à l'URL suivante: http://www.securityfocus.com/vdb/stats.html(...) tu vas y découvrir qu'en 2000 Linux a fait plus fort que Windows 3.11, 95 et 98 réunis et qu'en 2001 il est toujours en tête devant le trio infernal (30 contre 4)!!!

      ROTFL...

      --
      'tain là ca va saigner :-)
      • [^] # Re: News BSD / Troll

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

        Le nb d'advisories dans Bugtraq ne prouve rien.

        Si il y a peu d'advisories, c'est soit que personne n'utilise l'OS, soit que l'OS est très fermé et qu'on ne peut pas y faire grand chose.

        Linux a le plus d'advisories car les sources sont dispo et beaucoup de monde travaille dessus à améliorer sa sécurité. C'est plutôt bon signe.
        • [^] # Re: News BSD / Troll

          Posté par  . Évalué à 0.


          > Le nb d'advisories dans Bugtraq ne prouve rien.
          >
          > Si il y a peu d'advisories, c'est soit que personne n'utilise l'OS,

          Ce qui n'est certainement pas le cas des *BSD

          > soit que l'OS est très fermé et qu'on ne peut
          > pas y faire grand chose.

          Là d'accord: je pense aux VMS et autres.

          > Linux a le plus d'advisories car les sources sont dispo

          comme les *BSD

          > et beaucoup de monde travaille dessus à améliorer sa sécurité.

          Beaucoup d'efforts que les fabriquants de distros de merde réduisent à néant.

          > C'est plutôt bon signe.

          Non c'est inquiétant, il n'y a qu'à regarder le score de mdk :-((

          LFS vaincra !!!

          Bon, pour le ton comme pour la forme, je pensais être dans un troll...
        • [^] # Re: News BSD / Troll

          Posté par  . Évalué à 0.

          Le nb d'advisories dans Bugtraq ne prouve rien.

          >> hum, ils ne sont pas lu que par des admins
          >> et quand on sait le nombre de script kiddies
          >> qui partent les lire, je prefere que mon OS
          >> ne figure pas trop dedans que devoir supporter
          >> 120 attaques par jour ;)

          Si il y a peu d'advisories, c'est soit que personne n'utilise l'OS, soit que l'OS est très fermé et qu'on ne peut pas y faire grand chose.

          >> OpenBSD est tres utilise, peut etre pas autant
          >> que Linux ou FreeBSD, mais c'est du au nombre
          >> moins grand d'applications portees. Mais il est
          >> tres utilise du cote des firewall et peut etre
          >> un serveur web/ftp/mail sans rien avoir a
          >> envier a Linux ou Free. S'il a peu d'advisories
          >> c'est parcequ'un travail colossal d'audit est
          >> effectue ce qui n'est le cas ni de Linux ni de
          >> FreeBSD...
          >> Faut pas chercher plus loin :)

          Linux a le plus d'advisories car les sources sont dispo et beaucoup de monde travaille dessus à améliorer sa sécurité. C'est plutôt bon signe.

          >> OpenBSD a aussi les sources dispo et beaucoup
          >> de monde travail dessus, la plupart etant des
          >> white hat hackers en quete de gloire (haXor
          >> OpenBSD ca assure une réputation a vie ;p).
          >> Cela etant, contrairement a Linux, on ne trouve
          >> pas une faille a chaques fois qu'on se penche
          >> sur le sources...
          >> (désolé c'était facile :p)
      • [^] # c'est tres interessant

        Posté par  . Évalué à 0.

        et tu es capable d'en sortir beaucoup, des conneries comme ça ?
  • # iptables c'est mieux...

    Posté par  . Évalué à 0.

    > IPFilter, qui est aux *BSD ce que IPChains est
    > à Linux (mais en beaucoup plus puissant)

    Il ne faut pas comparer ipchains à ipfilter mais plutot iptables à ipfilter.
    • [^] # Re: iptables c'est mieux...

      Posté par  . Évalué à 0.

      iptables ne vérifie pas les numéros de séquences TCP dans une connexion établie.
      • [^] # Re: iptables c'est mieux...

        Posté par  . Évalué à 0.

        > iptables ne vérifie pas les numéros de
        > séquences TCP dans une connexion établie.

        Pour les incultes comme moi, ca sert à quoi de vérifier les numéros de séquences TCP dans une connexion établie ?
        • [^] # Re: iptables c'est mieux...

          Posté par  . Évalué à 0.

          Pour que quelqu'un d'autre n'utilise pas le canal
          précédement ouvert pour passer au travers des
          règles de filtrage.

          Il faudrait vérifier, mais a une certaine époque
          IP Filter était le seul "stateful" à tester les
          numéros de séquence TCP.

          Je dois avoir tord maintenant: http://www.hsc.fr/ressources/presentations/netfilter-2.4/netfilter-(...)

          Il semblerait que les gens qui ont implémenté netfilter/iptables se sont inspirés d'IP Filter
          • [^] # Re: iptables c'est mieux...

            Posté par  . Évalué à -1.

            Il semblerait que les gens qui ont implémenté netfilter/iptables se soient inspirés d'IP Filter.

            Ils auraient peut-être pu l'utiliser au lieu de s'en inspirer... Ca ne devait pas être assez bien pour eux!!

            Hop, -1 au score:-)
      • [^] # Re: iptables c'est mieux...

        Posté par  . Évalué à 0.

        Après ipfw, ipchains, iptables...
        Pour le noyau 2.6, ils vont nous faire ipblock ?

        Remarque que si ils en profitent pour rendre
        la syntaxe un peu moins à chier, ce sera
        un grand pas en avant.
        </troll>
        • [^] # Re: iptables c'est mieux...

          Posté par  . Évalué à -1.

          Après ipfw, ipchains, iptables... Pour le noyau 2.6, ils vont nous faire ipblock ?

          Non, IPCecater.
        • [^] # Re: iptables c'est mieux...

          Posté par  . Évalué à 0.

          Tout à fait d'accord, la syntaxe est illisible et favorise les erreurs.

          J'apprécierais aussi d'avoir un chargement atomique des régles, comme sur ipfilter, et pas par scriptage commande par commande.

          Si c'était possible aux concepteurs de s'inspirer de ce qui existe et de ne pas renouveler à chaque version majeure du noyau...
          • [^] # Re: iptables c'est mieux...

            Posté par  . Évalué à 0.


            > Si c'était possible aux concepteurs de s'inspirer de ce
            > qui existe et de ne pas renouveler à chaque version majeure du noyau...

            Dire qu'en 2.0.3x on avait IP Filter. Dégradé, certes, mais avec le stateful...
        • [^] # Re: iptables c'est mieux...

          Posté par  . Évalué à 0.

          Patience les BSDistes, votre heure de gloire viendra. Pour le moment, la mode c'est Linux, demain ça sera *BSD! C'est la vie!
          ....
          En attendant, allez jouer ailleurs ;-)
          • [^] # Re: iptables c'est mieux...

            Posté par  . Évalué à 0.

            Le jour ou BSD sera à la mode, je passe à Plan9 !!! :-))
            • [^] # Re: iptables c'est mieux...

              Posté par  . Évalué à -1.

              cool, un reb3lZ... :-P
              moi, le jour ou *BSD sera à la mode, je resterai sous nunux, comme ça je serai dans l'underground (puisque nunux ne sera plus à la mode ;-))
    • [^] # Re: iptables c'est mieux...

      Posté par  . Évalué à 0.

      Je ne connais pas bien ipfilter...qq connais une bonne url qui le compare à iptables de facon objective ??
    • [^] # Re: iptables c'est mieux...

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

      Je dis des conneries ou iptables il fait pas le stateful du tout ???

Suivre le flux des commentaires

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