Faille de Sécurité Linux

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
9
avr.
2001
Sécurité
A vérifier, mais une faille de sécurité assez cruciale, semble avoir été découverte dans les noyaux 2.2, comme l'article date du 28 Mars on ne peux exclure un poisson d'avril, je suis tombé sur la news et j'ai rien eu le temps de vérifier, à vos remarques ....
Note du modérateur: Effectivement il faut upgrader en 2.2.19.
Frédéric Raynal nous dit:
« D'après les messages que j'ai lus rapidement, l'idée est d'utiliser la fonction ptrace(). Le programme crée un processus fils puis le remplace avec le progamme SUID à exploiter (n'importe quel prog suid convient) via un execl(). Le processus fils conserve donc le même PID. Un signal est envoyé au processus père pour lui signaler que le prog suid est lancé. Dès lors, le père change les registres du processus fils de sorte à ce que le registre d'instruction %eip pointe sr le shellcode à exécuter. »

Aller plus loin

  • # Wazaaaaaa!

    Posté par  . Évalué à 1.

    Et hop! Une faille.

    bon, ce n'est ni la première ni la dernière...

    Mais pour sacrifier à la nouvelle "mode": à quand le "ver" exploitant cette faille?

    • [^] # Re: Wazaaaaaa!

      Posté par  . Évalué à 0.

      D'apres ce que j'ai compris. Il faut deja pouvoir lancer le script sur l'hote en question. Donc il faut que ton vers puisse se connecter et executer le script. Par contre a part telnet et ssh. J'aimerais savoir si d'autres demons permettent d'excuter des scripts a distance.
      J'ai pas le temps de recompiler le noyo de mon 486. Alors j'aimerais savoir si c'est urgent.

      Ce genre de news commence a devenir frequentes. Les gens vont prendre peur. Par contre si ça pouvait obliger a mettre a jour les logiciels ce serait pas mal. Faite un scan des serveurs ftp sur l'adsl, il y a pas mal de wu-ftp avec une version plus ancienne que la 2.6.0.

      • [^] # Re: Wazaaaaaa!

        Posté par  . Évalué à 1.

        Je sais pas si les gens vont prendre peur, mais je peux déjà te dire que l'arrogance et la morgue des Microsoftien se fait de plus en plus forte.
        Il est clair que Linux a perdu un de ses plus forts arguments (mais ça devait arriver...), et je ne sais plus trop quoi leur répondre. Dois-je relire le Linux Advocacy ?
        Je leur réponds que les trous et virus sont plus facilement, plus rapidement, et gratuitement corrigés, sans être dépendant d'un éditeur, mais cet argument paraît bien faible, puisque le mal est fait, et que payer n'est pas toujours rédhibitoire, surtout dans des entreprises bourrées de pognons.
        Je ne doute pas, bien sûr, mais parfois je me sens bien seul...

        • [^] # Re: Wazaaaaaa!

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

          Si tu veux leur répondre, tu leur parles du "bug unicode" et tu fais une recherche avec alatavista sur la chaîne suivante : "Welcome to IIS", ce qui te donneras beaucoup de réponses, et beaucoup de serveurs vulnérables.

          Le problème dans ls 2 cas est le même : une partie du boulot d'admin est de mettre à jour ses machines ... sauf que l'utilisateur moyen :
          1. il n'est pas admin
          2. il s'en fout d'avoir un type qui vient lui piquer ses photos de vacances sur don disque dur

          • [^] # Re: Wazaaaaaa!

            Posté par  . Évalué à 1.

            Rien a voir, la tu parles du serveur Web par de l'OS.

            Rien ne t'empeches d'utiliser Apache sous Windows.

            Cherches autre chose :+)

            • [^] # Re: Wazaaaaaa!

              Posté par  . Évalué à 1.

              Il y a quelques mois, une faille à été trouvé dans Apache sous Windows car une url style \toto\.......\hop permettait de remonter dans des repertoires parents. (un truc du genre. J'me rappelle plus exactement)

              Rien ne dit qu'il n'y a pas d'autres trucs non documenté du même style... Donc on évite Apache en prod sous Windows.

        • [^] # Re: Wazaaaaaa!

          Posté par  . Évalué à 1.

          Que répondre si des Windosiens te tracassent ?

          Bah... Sous linux on annonce quelles failles souvent difficiles à exploiter (dans le cas de celle-ci, faut déjà avoir un compte sur la machine) ou qui concernent des logiciels que peut de gens ont à mettre en oeuvre (serveur ftp ou DNS).

          Et ensuite tu rappelles que la dernière faille Windows/ie/Outlook (bref, ce que *tout le monde* utilise), permettait à n'importe qui d'executer n'importe quoi simplement en envoyant un mail...

          Ya quand même encore deux poids deux mesures...

          • [^] # Re: Wazaaaaaa!

            Posté par  . Évalué à 1.

            D'ailleurs, elle le permet toujours :) Jusqu'à ce que le correctif en Français/Allemand/Espagnol/Italien... sorte et que les gens l'utilisent. Remarquez qu'il semblerait que IE 5.00 ne soit pas affecté, installé par défaut sur un win98 SE.(enfin, en tout cas l'exemple sur kriptopolis ne marche pas sur une build 5.00.26qqch (testé au bureau), alors que ça marche au poil sur un 5.50.qqch (testé sur une machine en libre accès dans un centre commercial)

          • [^] # Re: Wazaaaaaa!

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

            > qui concernent des logiciels que peut de gens ont à mettre en oeuvre (serveur ftp ou DNS)
            Ouais mais quand t'installes une Mandrake ou une RedHat, les démons ftp et named tournent par défaut alors de toutes façons, si t'as pas un minimum de connaissances, tu te feras quand même piquer tes photos de vacances (où que dessus, c'est même pas ta femme mais celle du patron. Enfin, si le pirate bosse pas pour ton patron, tu t'en fous)

            • [^] # Faux!

              Posté par  . Évalué à 1.

              J'ai installer la Mandrake 8.0 Beta 3 ce week-end.

              En mode haute securite les daemon ftp et named ne tournent pas..

              • [^] # Re: Faux!

                Posté par  . Évalué à 0.

                Et le reste ? il tourne ?
                </trop facile>

      • [^] # Re: Wazaaaaaa!

        Posté par  . Évalué à 0.

        > D'apres ce que j'ai compris. Il faut deja pouvoir lancer le script sur l'hote en question.
        > (snip)
        > J'aimerais savoir si d'autres demons permettent d'excuter des scripts a distance.
        Au hasard, httpd ? Apache fait ca tres bien et tres vite, c'est sa specialitée mme :)
        > Alors j'aimerais savoir si c'est urgent.
        Bah ca va bientot faire une semaine qu'il est sortis, faudrai te depecher un chouya nan ? m'enfin, moi j'dis ca, j'dis rien...

        --
        ker2x (qui se demande pquoi il n'est plus authentifié)
        Qui n'a rien dis

  • # Debian 2.2r2

    Posté par  . Évalué à 1.

    Je viens de verifier dans dselect, il n'y a pas de version 2.2.19 (trop recente). Est ce qu'il y a moyen de savoir si le noyau 2.2.18 est vulnerable a cette attaque?

    Merci d'avance

    (si c'est le cas, va falloir que je me tape la compil des sources 2.2.19 a la pogne. groumpf)

    • [^] # Re: Debian 2.2r2

      Posté par  . Évalué à 1.

      il est vulnerable - comme tout les noyau 2.2 <=2.2.18

      • [^] # Re: Debian 2.2r2

        Posté par  . Évalué à 0.

        comme la plupart des noyaux 2.x mme
        y compris la serie 2.0.x,
        et les 2.4.x si tu n'actives pas une certaine options (mais je sais pas laquelle).
        (Tésté et approuvé)

        Il est marrant de remarquer que cette faille a été corrigée dans le 2.2.19 avant mme sa découverte :)
        Ou alors ? (FUD :p )

        --
        ker2x
        faché avec les cookies.

    • [^] # Re: Debian 2.2r2

      Posté par  . Évalué à 1.

      le lien bugtrack:

      "Here is exploit for ptrace/execve race condition bug in Linux kernels up to 2.2.18."

      les release notes de la 2.2.19:
      http://www.linux.org.uk/VERSION/relnotes.2219.html(...)
      "Ptrace/exec race
      Ptrace and exec as well as ptrace/suid races existed that could give a local user privileges."

      donc la 2.2.18 est vulnérable, la 2.2.19 non
      et cette vulnérabilité est pour les "local users"

  • # mouarf

    Posté par  . Évalué à 0.

    ...registre d'instruction %eip pointe...

    mais c'est toujours pour Linux x86 ce genre d'amusement !
    Bon, je continue à dormir sur mes 2 oreilles...

    • [^] # Re: mouarf

      Posté par  . Évalué à 0.

      C'est pas parce que l'exploit proposé sur bugtrack est limité aux machines x86 que la faille n'est pas exploitable sur toutes les architectures ....
      Bon de toutes facons c'est corrigé depuis plus de 15 jours et comme les administrateurs de machines linux font bien leur boulot, il doit plus y avoir de noyau < 2.2.19 en exploitation.
      De plus c'est un exploit pour utilisateurs locaux de la machine, or on sait tous que donner un login a qqun c'est toujours lui permettre de hacker la machine, quelle que soit l'architecture et la version d'OS qui tourne (windows, linux, solaris, hpux ...).
      PLuG

      • [^] # Re: charge d'un upgrade kernel

        Posté par  . Évalué à 1.

        > comme les administrateurs de machines linux font
        > bien leur boulot, il doit plus y avoir
        > de noyau < 2.2.19 en exploitation.

        T'es gentil mais si les admins devaient passer leur temps a recompiler le kernel a chaque nouvelle version, ils n'auraient le temps de rien faire d'autre.

        Imagine la charge de travail que représente le fait de recompiler un noyau sur UNE machine de prod, surtout si comme c'est fréquemment le cas, le kernel est patché (openwall, LIDS). Et ces 2 patches sortent rapidement après le noyau, alors que pour beaucoup d'autres il faut attendre plus longtemps, selon la forme de leurs mainteneurs...

        Alors imagine le temps (même sans les patches) passé à recompiler le noyau sur un parc de 50 machines *critiques*.

        Je connais plein de machines qui sont en 2.0.3*.

        Tout le monde n'a pas que le noyau de sa machine perso à tenir à jour. Et un upgrade kernel n'est *pas* une tâche anodine, surtout quand on touche à la production...

        Il est clair que des news comme ca ne font pas de bien à Linux... Remarquez, au moins on est sur que les vulnérabilités ne sont pas "étouffées" par un quelconque service de comm'. On retombe dans l'éternel débat "faut il dévoiler les failles de sécu, au risque de fournir des armes aux [cr|h]ackers".

        • [^] # Re: charge d'un upgrade kernel

          Posté par  . Évalué à 0.

          Je voulais savoir s'il y avait un moyen d'upgradrer le noyau sans redemarrer la machine. Car en prod, c'est souvent le principale probleme.

          • [^] # Re: charge d'un upgrade kernel

            Posté par  . Évalué à 0.

            Pas sous Linux. Sur certains machines professionnelles, en Solaris 8, je crois que c'est possible et encore: on peut mettre à jour le noyau, pas upgrader le kernel.

            • [^] # Re: charge d'un upgrade kernel

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

              Quelle est la différence entre "mettre à jour le noyau" et "upgrader le kernel" ?

              • [^] # Re: charge d'un upgrade kernel

                Posté par  . Évalué à 1.

                one is in english, l'autre en français ;)

                • [^] # Re: Re: charge d'un upgrade kernel

                  Posté par  . Évalué à 1.

                  oliv <olivier.ripoll@antispam.unine.ch> wrote:
                  > one is in english, l'autre en français ;)

                  Non, franglais :)

                  Simon.

                  --
                  [ "Life... Don't talk to me about life..." - Marvin ]

                  ---------------------------------------------------------------------------
                  Ce message a été envoyé par Usenet.
                  Path: not-for-mail
                  From: Simon Huggins <huggie-usenet@earth.li>
                  NNTP-Posting-Host: the.earth.li

        • [^] # Re: charge d'un upgrade kernel

          Posté par  . Évalué à 1.

          > Imagine la charge de travail que représente le fait de recompiler un noyau sur UNE machine de prod
          Tu peux toujours le compiler sur une machine de dével (en cross-compilation) et le déposer ensuite sur ta machine de prod. Tu peux ainsi factoriser la compil du noyau si t'as un parc de machines homogène (le point délicat restant toujours l'install du noyau et le reboot, je te l'accorde).

          > Je connais plein de machines qui sont en 2.0.3*.
          Ya au moins la mienne en 2.0.36 modifié (un bug ds le pilote oss). Mais le problème est que de plus en plus de softs utilisant les capacités du noyau ont besoin d'un 2.2.* ou 2.4.*, ce qui est normal.
          Là se pose la question du pourquoi changer de noyau ?, question dont la réponse est un compromis sécurité/fonctionnalités/temps passé à la recompil/upgrades nécessaires/je veux le dernier/etc

        • [^] # Re: charge d'un upgrade kernel

          Posté par  . Évalué à 0.

          Ma remarque etait une boutade, de l'humour quoi.
          Cependant, j'ai participé à la création d'une architecture qui une fois déployée représente plus de 2000 machines linux. Je peux te dire que j'ai prévu des moyens de mettre à jour à distance les logiciels installés sur ces machines (des serveurs centralisés sont chargés de gérer en conf les machines linux). Dans le cas de mises à jour simples (genre le produit samba), c'est facile. Pour le noyau comme il faut rebooter c'est plus chaud. Mais l'architecture que nous avons batie repose sur des machines linux redondantes 2 à 2 pour pouvoir en "sortir" une de prod (toutes les connexions se font sur l'autre temporairement, c'est un mode dégradé) pendant qu'on fait la maintenance.
          Bref, si vous déployez des 50aines de machines sans outils pour les gérer, et bien effectivement elles sont difficiles à gérer.
          Remarque: je ne travaille plus dans la meme boite mais je suis sûr que les 2000 serveurs en question sont toujours vulnérables vu que le temps de réaction de cette entreprise est tres long [pour corriger la faille, il faut planifier une réunion entre le chef de projet, le déploiement, un prestataire pour réaliser le package, faire des tests ... bref 15 jours c'est pas assez :-)]
          PLuG

        • [^] # Re: charge d'un upgrade kernel

          Posté par  . Évalué à 0.

          LIDS ...

          Si tu utilises LIDS, tu n'es pas vulnérable, pas besoin d'upgrader ton noyau (si tu as bien désactivé CAP_SYS_PTRACE dans les capacités par défaut) .


          -Jedi.

        • [^] # Re: charge d'un upgrade kernel

          Posté par  . Évalué à 0.

          > Je connais plein de machines qui sont en 2.0.3*.

          Je dois encore en avoir une ou deux en 1.2.13 !

  • # Euh...

    Posté par  . Évalué à 1.

    Sur une RedHat 7.0, avec un 2.2.18, en tous cas, ça ne marche pas :
    ptrace: PTRACE_ATTACH: Operation not permitted

    Ça fait la même chose sur un 2.4 ...

    • [^] # Re: Euh...

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

      La distribution n'a rien à voir avec la faille. Celle-ci provient de la version du noyau que tu utilises.

      Je l'ai testée sur un noyau 2.2.18, sans et avec le patch d'openwall, et je passe root sans les mains ;-)

      Je suppose que tu as mal fait un truc ou que tu as bidouillé ton kernel (genre tu as changé les syscalls via un modules ... enfin, toi ou un rootkit fondés sur les modules ;-)

      Tiens, qq'un a ssayé cet exploit avec un noyau "rootkité" (adore, knark ou autre ...), je serai curieux de savoir ce que ça donne :) Pour ceux qui ont testé, mailer moi directement svp (frederic.raynal@inria.fr)

      • [^] # Re: Euh...

        Posté par  . Évalué à 1.

        C'est probablement un noyau 2.2.18 modifié par Red Hat, modifications dont ils ont le secret et qui ne sont pas toujours très bien reçues...

        • [^] # Re: Euh...

          Posté par  . Évalué à 0.

          Dont ils ont le secret ? Un secret sous forme de .src.rpm en GPL ? vachement secret...

        • [^] # Re: Euh...

          Posté par  . Évalué à 0.

          oui surtout que le dernier noyau fournit par redhat sur rh 7 et sur rh 6.2 est le 2.12.17 :p

        • [^] # Re: Re: Euh...

          Posté par  . Évalué à 1.

          bmc <bmc@bmc.org> wrote:
          > C'est probablement un noyau 2.2.18 modifié par Red Hat, modifications
          > dont ils ont le secret et qui ne sont pas toujours très bien reçues...

          </FUD>

          Quel joli troll !

          En principe tous les paquetages du noyau de redhat (et d'autres
          distributions) sont disponible sous forme source.

          Ce n'est donc pas très secret.


          Simon.

          --
          [ "Have you seen a man who's lost his luggage?" -- Suitcase ]

          ---------------------------------------------------------------------------
          Ce message a été envoyé par Usenet.
          Path: not-for-mail
          From: Simon Huggins <huggie-usenet@earth.li>
          NNTP-Posting-Host: the.earth.li

      • [^] # Re: Euh...

        Posté par  . Évalué à 0.

        La distribution n'a rien à voir avec la faille. Celle-ci provient de la version du noyau que tu utilises.
        oui et non.
        Les noyaux Redhat sont dérivés des versions standard avec quelques patchs et modifications supplémentaires. Je ne sais pas ce que cela donne dans le cas précis de cette faille, mais on peut imaginer qu'une faille ne touche QUE redhat ou tout le monde SAUF redhat.

        PLuG

    • [^] # Re: Euh...

      Posté par  . Évalué à 0.

      T'as pas lu les explications, si ca marche pas, c'est paske le prog suid que tu utilises est dans le cache disque. Cela dit, moi il me met que ca marche, mais ca marche pas :)

      • [^] # Re: Euh...

        Posté par  . Évalué à 0.

        J'ai un noyau 2.2.14-5.0 de chez RH et il met :
        bug exploited successfully, mais il me demande le password (de la commande su ) ... et donc ça ne marche pas ...

    • [^] # Re: Euh...

      Posté par  . Évalué à 0.

      Pour info j'ai testé sur un noyau 2.2.15 et ça ne marche pas non plus :
      ptrace: PTRACE_ATTACH: Operation not permitted
      Error!

      Donc tous les noyaux 2.2 ne sont pas concernés ...

    • [^] # Re: "It has been broken in two places."

      Posté par  . Évalué à 1.

      Le source tel quel ne marche pas

      Comme c'est souvent le cas sur bugtraq, les exploits sont légèrement modifiés pour empêcher les script kiddies de venir se servir ("It has been broken in two places.").

      Seules les personnes disposant d'un minimum de connaissances en C pourront modifier le source en 2 endroits pour le rendre actif.

      A vos vi ;-)

  • # Et les noyaux 2.0.xx ?

    Posté par  . Évalué à 0.

    Et les noyaux 2.0.xx sont-ils concernés ?
    En effet, il y a une semaine, l'admin
    de l'ecole nous a demandé de changer tous nos
    mots de passes suite au "vole du fichier shadow"

    Bien qu'il n'ai donné aucune precision, je me demande comment les "voleurs" sont rentrés ... ;)

  • # L'utiliser!

    Posté par  . Évalué à 0.

    J'ai compilé le pg qui s'appelle epcs.
    Pour l'utiliser il faut passer en argument:
    ./epcs [victim] [address]
    Question, c'est quoi [victim] et c'est quoi [address]
    Merci.

    • [^] # Nan !

      Posté par  . Évalué à 0.

      Pas bien !

    • [^] # Re: L'utiliser!

      Posté par  . Évalué à 0.

      victim c'est le programme sur lequel tu applique l'exploit comme par exemple su ... il doit avoir le bit suid ... address c'est euh ... cf l'exploit sur bugtraq ...

Suivre le flux des commentaires

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