Trou de sécurité dans Netfilter

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes : aucune
0
6
mar.
2002
Sécurité
Des programmeurs ont trouvé un point de vulnérabilité dans Linux qui pourrait permettre à des utilisateurs malveillants d'accéder à un réseau sécurisé par le firewall.

Cette faille, qui affecte les version de Linux allant des versions 2.4.14 à 2.4.18-pre9, est située dans une composante du logiciel pare-feu Netfilter. Cette composante est impliquée quand deux utilisateurs d'ordinateurs discutent entre eux via le sytème "Internet Relay Chat (IRC)".

Tous les détails sur le lien...

Aller plus loin

  • # Un lien plus direct et plus technique

    Posté par  . Évalué à 10.

    http://www.netfilter.org/security/2002-02-25-irc-dcc-mask.html(...)

    (on le trouve sur la dépèche de news.com)

    PS: ça m'étonne de la part de Naxale une news aussi avare d'informations ;)

    • [^] # Merci pour l info;) En résumé

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

      Enfin c est une faille qui est dans le module irc de netfilter qui bind les ports;()

      @+
      Code34

      • [^] # Re: Merci pour l info;) En résumé

        Posté par  . Évalué à 2.

        Sauf que cette faille date du 27 fevrier ...
        faudrait se tenir plus au courant :-))

        -1 ca fait pas avancer le schmilblick

        • [^] # Re: Merci pour l info;) En résumé

          Posté par  . Évalué à 9.

          Je viens de passer hier en v1.2.5 de netfilter. Est-ce que la "fameuse" faille y est présente ou non ?

          Et autre point est-ce qu'il éxiste un patch pour cette version ?

          Merci

          • [^] # Re: Merci pour l info;) En résumé

            Posté par  . Évalué à 10.

            1.2.5, c'est ta version d'iptables, non ? ça n'a rien à voir avec la présence ou non de la faille dans le système de filtrage. Il faut pour ça regarder le numéro de version de ton noyau.

            • [^] # Re: Merci pour l info;) En résumé

              Posté par  . Évalué à 2.

              Yup ! J'ai un iptable 1.2.5 et un bon vieux kernel 2.4.18 installé hier pour mon eci adsl usb. Alors docteur ça donne quoi au final ?

              • [^] # Re: Merci pour l info;) En résumé

                Posté par  . Évalué à 4.

                "Cette faille, qui affecte les version de Linux allant des versions 2.4.14 à 2.4.18-pre9"

                Etant donné que le 2.4.18 a été arrêté au 25/02, je pense que oui tu as le droit de patcher ton noyau.

          • [^] # Re: Merci pour l info;) En résumé

            Posté par  . Évalué à 10.

            Le plus simple c'est de ne pas utiliser le module ipt_conntrack_irc, les DCC pourront ne plus marcher mais c'est tout...

    • [^] # Re: Un lien plus direct et plus technique

      Posté par  . Évalué à 9.

      Ton lien est plus intéressant, mais dans la news de news.com ils ont fait un bel effort de clarification de l'info, pour une fois... çà mérite d'être souligner.

  • # IRC ?...

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

    IRC c'est pour glander non ?!? Les moules n'ont pas besoin de l'IRC pour mouler. Je vois pas pourquoi les glands aurait plus de droits.

    Le jour où j'autoriserai l'IRC à travers un firewall important, il fera chaud ;-) !...
    (C'est quand même bien sur utile d'avoir de genre news.)

    • [^] # Re: IRC ?...

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

      Je ne vois pas où est le problème.

      Si on a besoin de sécurité, on ne va pas utiliser un logiciel libre, on utilise un programme qui est, dès la conception, orienté sécurité.

      Donc il faut bien s'attendre un jour ou l'autre a des grosses failles dans netfilter ou ipchains, alors qu'il existe des logiciels de coupe-feu bien supérieurs, comme checkpoint fw-1 ou cisco PIX.

      De plus, le source de ces pseudo-filtres étant ouvert, il est bien plus facile pour les hackers d'y trouver des failles qu'ils ne manqueront pas d'exploiter.

      Les décideurs ayant un minimum de jugeotte l'auront bien compris : si on veut de la sécurité, il faut payer un vrai logiciel de firewall, avec un vrai support commercial, c'est cher mais au moins on n'est pas déçu.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: IRC ?...

        Posté par  . Évalué à -2.

        trop gros, passera pas.
        Allez, hop, -1 histoire de voir si y'en a un qui marche dedans :-)

      • [^] # Re: IRC ?...

        Posté par  . Évalué à 0.

        De plus, le source de ces pseudo-filtres étant ouvert, il est bien plus facile pour les hackers d'y trouver des failles qu'ils ne manqueront pas d'exploiter.

        C'est pas parcequ'on a un logiciel dont les sources ne sont pas disponibles et qu'il faut payer qu'il sera plus sur, non?
        (Meme si c'est pas trop vrai dans le cas presente ici...)

      • [^] # Re: IRC ?...

        Posté par  . Évalué à 4.

        Ben moi je laisse pas passer ;-)

        ICAT nous dit (en faite la bd CVE)
        au cours de la dernière année:
        FW-1:
        -Buffer overflow remote sur la page d'admin (pas trop grave, peut d'IP doivent pouvoir y accéder)
        -DoS (CPU 100%) en foodant port 264 (grave)
        -DoS (CPU 100%+log énorme) dans certains cas avec des ip spoofés

        PIX:
        -Denis de service via un flood sur le serveur d'auth
        -IP disclosure des serveur FTP
        -Pb avec SMTP

        IPTable:
        -prob avec le module ftp qui permet une fois un serveur ftp à l'interieur du réseau de compromis de faire ce que l'on veut (très grave)
        -le pb avec irc

        Donc tous on autant de pb visiblement.
        Mais l'avantage du libre: si il y a un pb tout le monde le sait tout de suite (pas juste les services secrets israéliens pour FW-1 ou la NSA pour Cisco), et je ne parle pas des éventuelles Back-Doors...
        Tout est fait dans la TRANSPARENCE avec le libre.

        Honnetement, c'était de la pure provoc ou tu crois vraiment à ce que tu dis ???

        • [^] # Re: IRC ?...

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

          Chaque logiciel est susceptible d'avoir des vulnérabilités, les firewalls n'échappent pas à la règle. Ce qui compte c'est ce que fait le constructeur lorsqu'un trou de sécurité est découvert, et clairement personne n'arrive à la cheville du libre dans ce domaine : même si le développeur principal ne fait rien, il y a forcément quelqu'un qui sortira un patch, tandis que pour les logiciels propriétaires, on dépend du bon vouloir du constructeur. Si ce dernier n'existe plus, que fait-on ?

          Honnetement, c'était de la pure provoc ou tu crois vraiment à ce que tu dis ???

          J'utilise openbsd+[i]pf pour mes firewalls filtrants, et debian pour les proxies :-)

          Quant à pix et fw1; je les laisse à ceux qui préfèrent acheter une usine à clic plutôt que quelques journées d'expertise...

  • # Précisions sur la faille

    Posté par  . Évalué à 10.

    heu... quand je lis les commentaires si dessus, je les trouves un peu alarmants... :)
    à les lire, on dirait une mise en péril de la sécurité complète :)

    La faille est lasuivante :
    Le module 'espionne' les connections IRC pour y détecter les demandes de connections directs (DCC)
    Quand il en voie, il ouvre alors le port correspondant dans le pare-feu. La 'faille' est qu'il l'ouvre pour *toutes* les adresses, au lieu de seulement celle demandée.

    Alors je me pose la question :
    Au niveau exploitation, ça donne quoi ?
    Eh bien... pas grand chose. Cela veut dire que n'importe qui peut donc passer le pare-feu à travers ce port... àcondition de le connaitre, déjà. Et d'avoir quelqu'un qui écoute de l'autre côté.

    Pour conclure, je ne dirait pas que cette faille est inexploitable, mais je doute que l'on puisse en tirer vraiment partie... (sauf coup de chance, et en connaissant l'architecture réseau derrière...)

    • [^] # Re: Précisions sur la faille

      Posté par  . Évalué à 10.

      humm, c'est un peu simpliste ton histoire.
      On peux se servir de cette faille pour "s'échapper" d'un firewall.

      Par exemple imaginons que je veuille faire du napster. sympa mais personne ne peux se connecter sur ma machine parceque ce p...n d'admin qui fait le malin avec son linux a mis un firewall debian fait a la main.

      comme il a laissé le module conntrack_irc, je vais fabriquer un paquet irc spécial qui va demander au firewall de laisser entrer le port qui va bien pour toutes les machines internes et toute la boite pourra faire partie du reseau napster ...


      meme chose avec le port 80, 25, 21 ... voir 23 tien, pourquoi je laisserai pas mon poste carrement ouvert a l'exterieur en telnet ??

      d'ailleur, je vais meme ecrire un proxy socks qui tire parti de cette faille pour que tout le monde puisse faire tout ce qu'il veut en passant par mon proxy. NA.


      Bon de toutes manieres, laisser irc sur un firewall avec un vrai LAN derriere ... c'est le résultat de politiques comme "notre interface reflechit pour vous, pas besoin d'etre admin pour ca", en clair ca ne devrait pas exister sous linux d'ailleur cette faille n'a pas fait de bruit...

      • [^] # Re: Précisions sur la faille

        Posté par  . Évalué à -2.


        > d'ailleur, je vais meme ecrire un proxy socks qui tire parti de cette faille pour que tout le monde puisse
        > faire tout ce qu'il veut en passant par mon proxy. NA.

        Tout à fait. C'est ce que j'appelle le "major design flaw" de Netfilter.
        Content de voir qu'il y en a qui suivent, ipfilter roulaize

        Hop, -1

      • [^] # Use the source, Luke !

        Posté par  . Évalué à 1.

        Motivé par ma curiosité, j'ai vérifié la nature du patch. J'en ai retiré l'information suivante :

        La seule différence est au niveau de l'adresse IP destination. En effet, le "trou de sécurité" consistait en l'ouverture du port pour tout le réseau, alors que maintenant, le port est ouvert uniquement pour la machine qui est connecté au serveur IRC et qui à envoyé la commande DCC.

        Par rapport à ton point de vue et ton exemple, je concluerais donc qu'il est toujours possible de faire des trous dans le pare-feu grâce à ce module. Mais si l'on réfléchit un peu, on voie que malheureusement c'est son but. Il suppose en fait que la partie interne du réseau soit de confiance. (ie: pas d'utilisateurs qui puissent avoir les droits root, et chacun ayant une notion de savoir vivre...)

        Pour terminer, je dirais que de toutes manière, la seule chose qui devrait être dynamique sur un pare-feu, c'est la fermeture automatique de port, par exemple en cas de détection de port scan, mais certainement pas l'ouverture de ports.

        PS: je pense que ta remarque devrait être mise en bonne place dans les guides d'introduction à la sécurité pour Linux, afin que les administrateurs soient conscient de cela.

        • [^] # Re: Use the source, Luke !

          Posté par  . Évalué à 1.

          Effectivement, y en un 1 qui suit :-)
          Ma remarque n'etait pas motivée par le bug en question uniquement (en fait le bug porte sur un masque qui a "oublie" de fixer l'IP destination).

          Il faudrait ameliorer les modules conntrack pour decortiquer les protocoles qui passent dans le port ouvert. Si j'autorise le DCC irc, y a pas de raison de laisser passer du SSL natif (bon ok, avec une machine complice a l'exterieur, tout est toujours possible, par exemple encapsuler le SSL dans des faux fichiers qui passent en vrai DCC).
          Bref la securite c'est pas simple quand les utilisateurs veulent avoir accès a tout un tas de protocoles.

          Si j'avais du temps, je me pencherai bien sur la validation des protocoles. Il faudrait pouvoir dire: j'ai autorisé le port 80, si c'est autre chose que de l'HTTP couic on ferme.
          d'ailleur cela devrait etre en userland a brancher sur le module iptables qui demande la validation a un process userland ....

          faut murir le projet :-)

  • # voter pour moi

    Posté par  . Évalué à -6.

    JE REDUIRAIS LES IMPOTS COMME J'AI FAIT EN 1995 !!! JE SUIS LE PLUS GRAND !

Suivre le flux des commentaires

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