Journal Ça faisait longtemps: Local Root Exploit dans linux !

Posté par (page perso) .
Tags :
0
11
fév.
2008
Triste semaine que voilà mon journal.
Depuis quelque jours, la nouvelle est tombé dans toute les oreilles: un bug dans vmsplice permet d'élever ses privilèges de simple mortel à Dieu tout puissant.
Le code malfaisant est comme d'habitude sur milw0rm ici => http://www.milw0rm.com/exploits/5092 et là => http://www.milw0rm.com/exploits/5093
Heureusement un patch on-the-fly du kernel est possible: => http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploita(...)
Le kernel est déjà patché et les distributions devraient incessament sous peu distribué de nouveaux kernel patchés.

http://it.slashdot.org/it/08/02/10/2011257.shtml

----
NdM : Victor Stinner rajoute
Deux exploits root locaux circulent sur Internet : Linux Kernel 2.6.17 - 2.6.24.1 vmsplice Local Root Exploit et Linux Kernel 2.6.23 - 2.6.24 vmsplice Local Root Exploit.

Ils exploitent un bug dans l'appel système vmsplice(). Le noyau 2.6.24.1 corrige partiellement le bug et la version 2.6.24.2 semble le corriger définitivement.

Plus d'informations :
* LKML: "Niki Denev": kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit
* Gentoo : Gentoo Bug 209460 - kernel 2.6.17 - 2.6.24.1 splice: missing user pointer access verification (CVE-2008-{0009,0010})
* Ubuntu : Bug #190587 in linux (Ubuntu): “Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)”
* Debian : #464953 - linux-2.6: mmap() local root exploit - Debian Bug report logs

Les patchs dans le noyau : splice: fix user pointer access in get_iovec_page_array() (2.6.24.2) et splice: missing user pointer access verification (CVE-2008-0009/10) (2.6.24.1).

Identifiants CVE : CVE-2008-0009 et CVE-2008-0010.

  • # Commentaire supprimé

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

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

  • # Au sujet de disable-vmsplice-if-exploitable.c

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

    Extrait d'un email dans le rapport de bug Debian : « Just for the record: Do not use the "hotfix" named disable-vmsplice-if-exploitable.c. The hotfix first tries to run the exploit (which would be totally unnecessary for the actual "fix" by the way and is therefore a very dumb thing to do), and this still leads to kernel memory corruption which will render the system unstable. You can imagine what might come from corrupted kernel beside a simple crash (e.g. data loss). ».
    • [^] # Re: Au sujet de disable-vmsplice-if-exploitable.c

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

      En tout cas le code fonctionne chez moi.
      Les deux exploit echouent tout le temps.
      • [^] # Re: Au sujet de disable-vmsplice-if-exploitable.c

        Posté par . Évalué à 2.

        Pareil aucun problème visible apparemment en appliquant ce patch. Ca ne veut pas dire qu'il ne posera pas problème ailleurs.
        • [^] # Re: Au sujet de disable-vmsplice-if-exploitable.c

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

          Il y a un autre workaround qui consiste en un module kernel qui redirige vmsplice vers nosuchsyscall.
          Enfin c'est comme ça que je comprend ce oops:

          ------------[ cut here ]------------
          kernel BUG at /home/nico/novmsplice/novmsplice.c:59!
          invalid opcode: 0000 [#1]
          Modules linked in: novmsplice iptable_filter ip_tables it87 hwmon_vid hwmon i2c_isa xt_physdev x_tables i2c_i801 i2c_core
          CPU: 0
          EIP: 0061:[] Not tainted VLI
          EFLAGS: 00010287 (2.6.20-xen-r6 #1)
          EIP is at nosuchsyscall+0x0/0x4 [novmsplice]
          eax: 0000013c ebx: 00000004 ecx: bfde2a2c edx: 000000d8
          esi: 00000000 edi: b7f8d000 ebp: c6c30000 esp: c6c31fb4
          ds: 007b es: 007b ss: 0069
          Process jessica_biel_na (pid: 6408, ti=c6c30000 task=c6de4550 task.ti=c6c30000)
          Stack: c0104784 00000004 bfde2a2c 00000001 00000000 b7f8d000 bfde29d8 0000013c
          0000007b 0000007b c0410000 0000013c 0804825c 00000073 00000286 bfde29c0
          0000007b 08074e90 00000000
          Call Trace:
          [] syscall_call+0x7/0xb
          [] io_schedule_timeout+0x15/0x16
          =======================

          En tout cas, c'est vraiment pas discret maintenant :)
          ==> http://www.linux.it/~md/software/novmsplice.tgz
  • # fermer la porte à double tour

    Posté par . Évalué à 6.

    je sais que cela n'est pas forcément bienvenu de prendre à la légère une faille dans un système, mais "local root exploit" cela veut bien dire que cela ne fonctionne que depuis un accès local (et sans doute aussi via un accès type ssh en compte normal, ou sur un système multiutilisateur type école / serveur partagé) et non pas une faille qui compromet un système qui a un simple accès sur internet, il me semble important de le préciser.

    Donc avant de sortir de chez vous si vous n'avez pas le temps de patcher votre noyau : fermez la porte à double tour, ou barricadez-là, l'attaque ne pourra pas venir d'ailleurs !

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: fermer la porte à double tour

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

      Il y a pas mal de serveur Web sous Linux avec des script php foireux autorisant system();.
      Il ne suffit de pas grand chose pour que l'exploit, au lieu d'ouvrir un shell bash, télécharge un r00tk1t et le lance.
      • [^] # Re: fermer la porte à double tour

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

        Il suffit aussi d'une faille pré-existante (non patchée / mise à jour par l'admin') qui ne donnait auparavant "que" l'accès utilisateur en distant : d'un coup cet exploit avec l'utilisation de 2 failles successive donnerait un accès root en distant. Comme quoi la distinction local / distant n'est pas si éloignée pour ceux qui font un peu tourner tout et n'importe quoi comme services. Ensuite, si votre serveur n'est pas accessible d'internet, cela cantonne l'exploitation à votre réseau local (que vous maîtrisez sans doute un peu mieux).

        Effectivement pour ceux qui ont débranché le cable réseau c'est bon (sans aller jusqu'à éteindre le PC si vous n'en avez pas besoin et débrancher son cable d'alim' pour les plus paranos).
        • [^] # Re: fermer la porte à double tour

          Posté par . Évalué à 1.

          ouais vous avez parfaitement raison. Ma remarque était un peu (voire très) bête, surtout la partie "l'attaque ne pourra pas venir d'ailleurs", je n'avais pas pensé à php par exemple, même si je ne vois pas trop comment ils peuvent le faire, je suis certain que les crackers eux savent bien comment le mettre en application :)

          J'ai testé le code ici : http://www.milw0rm.com/exploits/5092 sur mon ordinateur perso, et cela fonctionne vraiment bien, c'est impressionnant !
          C'est mieux qu'un sudo, pas besoin de mot de passe ni même l'autorisation :)

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

          • [^] # Re: fermer la porte à double tour

            Posté par . Évalué à 5.

            Voici ce que je viens de voir sur un post du forum ubuntu-fr lui-même révélant les dires de OVH :


            Communiqué de OVH :
            Bonjour,
            Une importante faille de sécurité a été mise en évidence ce week-end
            sur l'ensemble des noyaux Linux 2.6.XX que vous pouvez utiliser chez
            Ovh (et pas seulement). Aucun patch de sécurité (grsecurity, PaX,
            Openwall, etc) ne bloque ce bug. La seule possibilité de fixer le
            bug est de mettre à jour votre kernel vers la dernière version de
            Linux 2.6.24.2 (mis à jour hier soir à 21H51 !!).

            Ce bug est TRÈS dangereux: n'importe quel utilisateur du serveur
            permet d'avoir les droits de root en moins de 10 secondes !! Très très
            simplement. En suite c'est foutu car il fait réinstaller le serveur.
            Même si vous ne proposez pas de shell/bash sur vos serveurs, à travers
            les scripts php, cgi etc on peut avoir l'accès root sur la machine.

            Ne remettez pas à demain ou à ce soir cette mise à jour ! Il y a 1h
            environ, on vient de bloquer le 1er serveur hacké avec cette méthode.
            Et avec ce bug, c'est la sécurité du réseau qui est en dangers. Nous
            n'allons donc pas hésiter 1 seconde de bloquer votre serveur s'il est
            hacké. Prenez donc 10 minutes là pour exécuter ces quelques commandes
            simples.

            Ovh propose des noyaux patchés, verifiés et sécurisés contre ce bug
            de sécurité. Aussi, le nouveau noyau supporte mieux les cartes réseaux
            utilisés sur le hardware chez Ovh, l'iSCSI, ainsi qu'une tonne de
            petits bugs du Kernel.

            Comment mettre à jour le noyau en moins de 5 minutes ? Très simplement.
            Même si vous n'avez jamais fait, vous allez réussir cette mise à jour smile

            1.)
            Connectez vous sur le serveur en SSH et tapez (copier coller):
            # wget -q ftp://ftp.ovh.net/made-in-ovh/dedie/pat … e-sysfs.sh -O - | /bin/bash
            # wget -q ftp://ftp.ovh.net/made-in-ovh/rtm/install_rtm.sh -O - | /bin/bash
            Ceci met à jour votre RTM, le patch sysfs, 3ware. Une sécurité de plus
            avant le reboot.

            2.)
            Dans le manager, choisissez "netboot" et puis "ipv4", puis la version
            "32bits" ou "64bits" (ça dépend la distribution que vous utilisez)
            Par exemple "bzImage-xxxx-std-ipv4-32"
            En suite reconnectez sur sur le serveur en SSH et tapez
            # reboot
            Attendez le redémarrage du serveur (entre 2 et 5 minutes en fonction du
            serveur) puis reconnectez-vous sur le serveur en SSH puis tapez:
            # uname -a
            La commande doit vous renvoyer la version 2.6.24.2. Par exemple:
            # uname -a
            Linux oles2.ovh.net 2.6.24.2-xxxx-std-ipv4-32 #1 SMP Mon Feb 11 14:51:26

            Si vous n'utilisez pas le netboot, vous pouvez telecharger nos noyaux
            sur ftp://ftp.ovh.net/made-in-ovh/bzImage
            bzImage-2.6.24.2-xxxx-std-ipv4-32
            bzImage-2.6.24.2-xxxx-std-ipv4-32-hz1000
            bzImage-2.6.24.2-xxxx-std-ipv4-64-hz1000
            bzImage-2.6.24.2-xxxx-std-ipv6-32
            bzImage-2.6.24.2-xxxx-std-ipv4-32-filer
            bzImage-2.6.24.2-xxxx-std-ipv4-64
            bzImage-2.6.24.2-xxxx-std-ipv4-64-rescue
            bzImage-2.6.24.2-xxxx-std-ipv6-64

            Les noyaux GRSecurity ne sont pas encore disponible. Le patch sera dispo
            sous quelques jours.

            Si vous compilez vous-même le noyau, vous pouvez trouver notre .tar.gz
            ainsi que les .config sur ftp://ftp.ovh.net/made-in-ovh/bzImage

            Si vous avez des problèmes, merci d'utiliser le forum ou la mailing list
            afin qu'on vous aide très directement. N'oubliez pas mettre le nom de
            votre serveur dédié dans vos messages (chaque message). Sur le forum:
            http://forum.ovh.com/showthread.php?t=31396

            Merci à tous et bon patch !

            Les clients qui ont pris l'option sécurité totale sont en cours de mise
            à jour (déjà).

            Amicalement
            Octave
            • [^] # Re: fermer la porte à double tour

              Posté par . Évalué à -2.

              rassure moi, tu n'as pas fait un cc de leur communiqué .
              Parce que le ton (un peu trop copain pour un pro a mon gout) et les fautes d'ortho , voila quoi /o\
              • [^] # Re: fermer la porte à double tour

                Posté par . Évalué à 6.

                Toi, tu ne connais pas Octave d'OVH ;) Je ne sais plus quel est son poste exact, mais ça ressemble effectivement à un de ses posts. Il faut néanmoins savoir qu'il n'est pas français (Polonais je crois), ce qui explique les fautes.
                Pour le ton, je saurais pas dire, je l'ai toujours vu parler comme ça sur la mailing / ng, la première fois ça surprend, après ça passe tout seul
  • # Pourquoi donner le source ?

    Posté par . Évalué à 0.

    Quel est l'interet de fournir le source qui ne nécessite qu'une compil' pour avoir un shell root ?

    Pour que les admins puissent tester leurs machines ok, sauf que la n'importe qui, qui a un shell sur une machine ou il ne doit pas etre root peut l'etre en 20sec.


    Quel est donc l'utilité de mettre le source à disposition de tout le monde aussi facilement ?
    • [^] # Re: Pourquoi donner le source ?

      Posté par . Évalué à 10.

      Quel est donc l'utilité de mettre le source à disposition de tout le monde aussi facilement ?

      Que tout le monde ait l'info et ait un outil de vérification?

      De toutes façons, la sécurité par l'obscurité, ça marche pas plus d'une demie journée pour ce genre de trucs...
      • [^] # Re: Pourquoi donner le source ?

        Posté par . Évalué à 3.

        Ce qui laisse une demie journée de battement aux admins pour mettre à jour leur park.

        Je me mets à la place de l'admin en fac d'info, il a du se jeter sur le cable reseau...
        • [^] # Re: Pourquoi donner le source ?

          Posté par . Évalué à 5.

          Ce qui laisse une demie journée de battement aux admins pour mettre à jour leur park.

          En pratique, le temps de réaction est toujours plus lent que ça... faut être couillu pour changer le noyau sur des serveurs de prod en une demie journée sans faire de tests de régression...
        • [^] # Re: Pourquoi donner le source ?

          Posté par . Évalué à 2.

          Surtout que la faille est connue depuis vendredi...
        • [^] # Re: Pourquoi donner le source ?

          Posté par . Évalué à 2.

          l'admin en fac d'info, il s'en fiche, il a un parc sous (open)solaris :D

          ==> []
          • [^] # Re: Pourquoi donner le source ?

            Posté par . Évalué à -1.

            l'admin en fac d'info il risque de voir des étudiants "casser" les postes de travail des étudiants et de polluer leur propre réseau de travail , laissant indifférent les employés et enseignants.

            les étudiants se font du mal à eux même.

            -
            les serveurs eux sont hors d'atteinte de tout code permettant de l'exécution distante ou de login par des personnes extérieures au service informatique.

            ce qui laisse de quoi préparer tranquillement les mises à jour sans risque de régression.

            et non, je n'ai pas de parc sous (open)solaris pour simplement des postes de travail matlab et autres nastran pour les étudiants.
    • [^] # Re: Pourquoi donner le source ?

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

      Parceque l'obscurantisme c'est pas bien ?

      Le mieux c'est pas de l'éviter mais d'y faire face et de la corriger dans un délai minimal. Apres si les admins systemes ne mette pas à jour leur systemes c'est un autre probleme.
    • [^] # Re: Pourquoi donner le source ?

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

      Le suite hebergeant les exploits est un site anarchiste donc l'utilité est de permettre la venu de l'anarchie par la destabilisation des structures en place.
    • [^] # Re: Pourquoi donner le source ?

      Posté par . Évalué à 2.

      Parcequ'il est important de croire en son prochain ?
      Parceque le libre arbitre est censé aider les gens à ne pas être débile/faire des choses débiles ?
      Parceque ça pourrait aider à hacker le site du FN si il tourne sous mollusk ?

      En fait, la vraie question est "pourquoi ne pas donner le source ?"
      Si Ta réponse est "pour éviter le hack", sache que les hackers se passent ce genre de choses très rapidement. Ensuite et bien le coup de "Le pouvoir sait mieux que vous ce qui est bon pour vous" est -selon moi- une très mauvaise chose (confer hack-tualités et autres "traités-faits-par-simplet"...
      • [^] # Re: Pourquoi donner le source ?

        Posté par . Évalué à 5.

        Si Ta réponse est "pour éviter le hack", sache que les hackers se passent ce genre de choses très rapidement.

        Bon, maintenant il est clair que cet exploit est diffusé à un plus grand nombre de personnes que les hackers classiques et que les script kiddies vont s'en donner hacker joie ...

        Mais de toutes façons, la sécurité par l'obscurité, ça se résume souvent à un veilleur de nuit aux yeux bandés traquant des cambrioleurs équipés de lampes de poches...
        • [^] # Re: Pourquoi donner le source ?

          Posté par . Évalué à 3.

          mis a part faire chier les admins linux je vois pas trop l'interet d'avoir divulgue partout le code pour script kiddies avant de prevenir les hackers du kernel et les distributions du probleme. La securite par l'obscure je suis pas pour mais par contre signaler les failles de ce style a grand renfort de publicite et cela sans donner le temps d'avoir une correction c'est pas trop normal ni ce qui est demande par tous les experts de securite.
          • [^] # Re: Pourquoi donner le source ?

            Posté par . Évalué à 4.

            « d'avoir divulgue partout le code pour script kiddies avant de prevenir les hackers du kernel »
            Ben on te file la faille ET la nouvelle version du kernel qui la corrige *en même temps*, je crois que les « hackers du kernel » sont donc bien au courant, et ont déjà réagit, non ?

            Donc tout va bien, t'es au courant toi, tu as la solution pour corriger ton problème, l'affaire est entendue, les choses ont été faite au plus vite et au mieux, non ?

            Yth.
            • [^] # Re: Pourquoi donner le source ?

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

              tout le monde a l'air de se réjouir à coup de "la sécurité par l'obscurité sai le mal", je ne comprends pas trop ça n'est pas la question ici... Je trouve que c'est un peu un comportement de trou du cul de placarder un exploit gros comme ça un peu partout sur l'internet (slashdot,..) sans laisser quelques jours aux acteurs majeurs (debian , rh etc) pour mettre à disposition des noyaux patchés
              • [^] # Re: Pourquoi donner le source ?

                Posté par . Évalué à 1.

                Oui.

                Mais on serait des trous du cul si on empéchait les trous du cul de le faire.
                Faut vivre avec. Le monde parfait n'existe pas.
              • [^] # Re: Pourquoi donner le source ?

                Posté par . Évalué à 5.

                La sécurité par l'obscurité ça marche dans un seul cas : pour se protéger des attaques aléatoires quand tout le monde fait une chose d'une certaine manière, et toi d'une autre que tu ne divulgues pas.

                Par exemple mettre ton ssh sur un autre port que le 22 est efficace *uniquement* parce que la très grande majorité des gens le laisse sur le port par défaut. Les cracker ou autres script-kiddies qui cherchent une machine à compromettre en cherchent une facile, ils en testent plein et tapent sur la plus faible.

                Ca serait complètement inutile si par exemple quelqu'un cherchait à entrer chez toi précisément, il doit falloir dix secondes de scan pour trouver sur quel port se trouve ton ssh.


                Une faille de sécurité comme celle-ci, mieux vaut en parler beaucoup, partout, que les gens soient au courant et mettent à jour, mine de rien si la majorité des machines sont à jour, ça rend le travail de recherche d'une machine vulnérable nettement plus difficile, et peut suffire à protéger ceux qui ne se sont pas foulés.

                Yth.
                • [^] # Re: Pourquoi donner le source ?

                  Posté par . Évalué à 6.

                  Une faille de sécurité comme celle-ci, mieux vaut en parler beaucoup, partout, que les gens soient au courant et mettent à jour

                  Le problème c'est justement qu'on en a parlé beaucoup, partout, avant que les gens ne puissent mettre à jour. On n'a pas laissé le temps aux distribs de publier les mises à jour. Il aurait suffit de 3 ou 4 jours, ça aurait permis aux packagers de bien faire leur boulot, de mener leurs tests et de faire une publication sereinement, au lieu de ça tout a été fait dans la précipitation et l'exploit a été diffusé avant le correctif officiel.

                  Ne me fait pas croire que ne pas divulguer un exploit pendant 3 jours c'est de la sécurité par l'obscurité. Surtout qu'à la limite, ce n'est pas tant le fait d'avoir révélé le problème qui est reproché, c'est d'avoir publié un exploit accessible au premier décérébré venu en même temps que la faille.

                  Pour conclure je pense que vous ne savez pas ce que c'est que la sécurité par l'obscurité. Garder une faille découverte secrète pendant quelques jours en prévenant l'auteur du soft, et lui laisser ce laps de temps pour ne pas tout faire dans la précipitation, ce n'est pas de l'obscurité, et c'est d'ailleurs comme ça que ça se passe dans la majorité des cas. Jusque là je n'ai entendu personne se scandaliser qu'une faille ne soit révélée que le jour où le correctif est présent (lorsque le délai est raisonnable bien entendu).
                • [^] # Re: Pourquoi donner le source ?

                  Posté par . Évalué à 0.

                  /!\ Mon message a mal été compris apparement. /!\

                  Je ne critique pas le fait de faire que tout le monde soit au courant de cette faille, il le faut. Mais que le premier venu puisse l'exploité aussi facilement ...
                  Que tout le monde explique le fonctionnement de l'exploit, les mécanismes du pourquoi. Oui, il faut le diffuser pour pas que ca se reproduise.

                  "Ca serait complètement inutile si par exemple quelqu'un cherchait à entrer chez toi précisément, il doit falloir dix secondes de scan pour trouver sur quel port se trouve ton ssh."
                  Tout à fait d'accord, la personne qui veut s'introduire sur un serveur, fera tout ce qu'elle peut pour y rentre, mais pourquoi lui facilité la tache?

                  Mais donner le fichier .c qui fait tout tout seul. Je ne vois pas l'interet, c'est un peu comme donner une arme aux "méchants" en leur disant "de toute façon vous en trouverez".
                  Si je vous écoutes il faudrait enlever les alarmes, les caméras vidéos dans les banques puisque de toute façon ca n'empeche pas le vol mais ca ne fait que ralentir ...

                  Comme le dit l'expression "C'est l'occasion qui fait le larron".
                • [^] # Re: Pourquoi donner le source ?

                  Posté par . Évalué à 4.

                  Exemple simpliste, si tu as à la fois un algo à toi aussi fort que les algos actuels question sécurité et qu'en plus tu es le seul à t'en servir, on me fera pas croire que tu ne gagnes pas un peu en sécurité ...
                  • [^] # Re: Pourquoi donner le source ?

                    Posté par . Évalué à 3.

                    C'est exactement ce que je dis avec l'exemple du ssh.
                    Changer un port c'est à la portée de n'importe qui en plus c'est trivial.

                    Tu peux faire le test, si tu as une machine sur internet, ou sur laquelle tu transfère le port 22, tu logges les tentatives de connexion sur le port ssh, et tu vois que tu te prends des vagues d'attaques régulières, de parfois plusieurs heures, et plusieurs fois dans la journée, des tentatives de login/mot de passe, des trucs bizarres...

                    Change de port ensuite, et tout disparaît.

                    Tu gagnes donc énormément en tranquillité, mais uniquement contre les attaques aléatoires, et pas vraiment en sécurité contre ce qui est dirigé contre toi directement.


                    Bref, à mon avis ça ne change pas grand chose que le script ait été fournis ou pas, un équivalent devait déjà traîner sur des sites de crackers.
                    Il ne doit pas falloir plus de quelques heures à un type qui s'y connaît pour exploiter une faille quand on la lui montre du doigt.


                    Enfin, c'est mon avis, et je pense vraiment que très peu de mal a été causé par le fait de fournir le code directement, et qu'au contraire ça peut filer un coup de fouet aux admins systèmes un peu paresseux qui vont tester pour le fun et voir que ça marche au poil. Ca oui, ils auront passé une demi-journée stressante, mais c'est mieux que de se retrouver dans trois mois avec un type qui fout tout en l'air parce que la faille a été oubliée dans un coin.
                    Encore une fois c'est juste mon avis...


                    Yth.
                    • [^] # Re: Pourquoi donner le source ?

                      Posté par . Évalué à 2.

                      Tu prends un exemple ou "trivial à changer" est à peut prêt équivalent à "trivial à détecter" et "trivial à contourner".

                      Ce qui est pas forcément le cas.
                    • [^] # Re: Pourquoi donner le source ?

                      Posté par . Évalué à 1.

                      Tu peux faire le test, si tu as une machine sur internet, ou sur laquelle tu transfère le port 22, tu logges les tentatives de connexion sur le port ssh, et tu vois que tu te prends des vagues d'attaques régulières, de parfois plusieurs heures, et plusieurs fois dans la journée, des tentatives de login/mot de passe, des trucs bizarres...

                      Change de port ensuite, et tout disparaît.

                      Tu gagnes donc énormément en tranquillité, mais uniquement contre les attaques aléatoires, et pas vraiment en sécurité contre ce qui est dirigé contre toi directement.


                      Ce que tu gagnes, c'est surtout d'avoir moins de log à parser en cas d'attaque plus sérieuse.

                      bon sinon avec pf on peut toujours s'amuser avec des :

                      table persist
                      block quick from
                      pass quick proto { tcp, udp } from any to any port ssh \
                      flags S/SA keep state \
                      (max-src-conn 10, max-src-conn-rate 5/2, \
                      overload flush global)

                      et le calme revient :)
                      • [^] # Re: Pourquoi donner le source ?

                        Posté par . Évalué à 1.

                        Donc tu confirme que meme si ca n'augmente la sécurité que d'un petit rien, ce rien est quand même appréciable ?

                        Mettez vous 2sec a la place de l'admin qui a un serveur qu'il ne peut pas rebooter comme il veut pour X raisons, et qu'il a des utilisateurs qui se connectent dessus, que ces utilisateurs n'ont pas les compétences pour implémenter de tel mécanismes(ce qui doit être a vu de nez plus de 50% des utilisateurs de linux)
                        Maintenant dans ces utilisateurs combien vont "essayé" le .c qu'ils vont trouver sur leur site de news linux favoris ?

                        La faille est connu depuis longtemps : Surement
                        Mais moi simple developpeur, je n'ai vu la faille que parce que je lis linuxfr, je n'aurais pu être root sur une machine ou je n'avais pas le droit que parce que je lis linuxfr et que j'ai cliqué sur tous les liens de la news.

                        Mon admin attendait deseperement une maj debian qui est arrivé vers 17-18h le jour de poste de ce journal(je ne le critique pas il fait ce qu'il peut)

                        Tout ca pour dire que cacher l'info c'est mal, mais faciliter l'exploitation d'une telle faille c'est encore plus mal.
    • [^] # Re: Pourquoi donner le source ?

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

      Ouais je suis d'accord. Il faut trouver un juste milieu entre diffuser un code source pour pointer la gravité du problème et le diffuser à vraiment tout le monde.

      Là n'importe qui capable de faire gcc exploit.c -o exploit && ./exploit peut l'exploiter...
      C'est quand même un problème. Je sais que dans mon école, ya des trucs qui ne sont pas super sécurisés mais on sait bien que personne ne va l'exploiter, se donner la peine de faire des recherches etc.
      Alors que là, c'est super tentant quand même ! (non je vous rassure, j'en ai surtout parlé au responsable)

      Imaginez, être root en 30 secondes à peine... C'est vraiment trop à la portée de tous.
      • [^] # Re: Pourquoi donner le source ?

        Posté par . Évalué à 2.

        pourquoi le compiler ? il le télécharge :) il y a d'ailleurs des tas de scripts qui profitent d'applis trouées et de configurations bancales (PHP...) pour ça
  • # Fix pour debian dispo

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

    Les mise à jour de sécurité pour debian etch sont déjà dispos :

    http://lists.debian.org/debian-security-announce/debian-secu(...)

    M.
  • # x86 only

    Posté par . Évalué à 0.

    Petite précision : cet exploit ne marche que sur x86 (i386 et x86_64).
    Vive les PPC \o/
    (meme si vu la gueule du code, i.e. mettre 2 ou 3 trucs sur la pile et faire un return, ca doit etre adaptable a d'autres archis ...)
    • [^] # Re: x86 only

      Posté par . Évalué à 2.

      des "fixes" existent pour les autres archis que x86 (cf. http://lists.debian.org/debian-security-announce/debian-secu(...) ) donc sans doute que cet "exploit" ne marche pas tel quel sur les autres archis, mais la faille est bien présente ailleurs.
      • [^] # Re: x86 only

        Posté par . Évalué à 2.

        Ces fixs contiennent aussi une correction pour un exploit d'un problème des vserver. Ça doit être pour ça que les autres archis sont concernées.

        Pour ce bug en particulier, dans l'exploit tu vois bien du :
        "movl %0, 0x10(%%esp) ;"
        "movl %1, 0x0c(%%esp) ;"
        "movl %2, 0x08(%%esp) ;"
        "movl %3, 0x04(%%esp) ;"
        "movl %4, 0x00(%%esp) ;"
        "iret"

        et encore un :
        #else
        #error "unsupported arch"
        #endif

        si c'est pas i386 ni x86_64 ...
        • [^] # Re: x86 only

          Posté par . Évalué à 4.

          > si c'est pas i386 ni x86_64 ...

          Ça montre seulement que la démonstration de l'exploitation de la faille a été faite sur i386 et x86_64.
          Ça n'indique pas que la faille n'existe pas sur ppc.
          La faille existe pour toutes les architectures.
          • [^] # Re: x86 only

            Posté par . Évalué à 2.

            Hoaa, c'est bon, tu chipotes, j'avais indiqué dès le début que ça devait être faisable sur d'autres archis. C'est juste pas encore sorti ... enfin, on sait pas.

            Mais bon, si on peut même plus troller tranquille ...
  • # Depeche de premiere page?

    Posté par . Évalué à 3.

    Je trouve que ce bug est assez grave et impact enormement de monde, surtout avec cette mode debile du serveur dedie linux a pas cher (gere par des purs newbies - ca n'est pas pejoratif - qui n'auront pas forcement vent de ce probleme de securite).

    Il serait donc probablement judicieux de rediger une depeche de premiere page pour les gens qui regardent juste linuxfr a la va vite (et c'est surement le seul site de news linux qu'ils regardent)

    est ce que quelqu'un s'est deja devoue? sinon je fais un truc dans la journee...
    • [^] # Re: Depeche de premiere page?

      Posté par . Évalué à 5.

      c'est rapporté dans tous les sites dédiés à la sécurité et toute les distribs publient les failles et correctifs dans ce cas la.

      Ceux qui sont aveugles à ça ne vont pas être "sauvés" par linuxfr...
      • [^] # Re: Depeche de premiere page?

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

        corrigé même dans les distrib sorties avec le 2.6.17, cad il y a plus d'un an?

        La news LinuxFR sera surement rerise par d'autres sites d'informatique plus généralistes
  • # CVE

    Posté par . Évalué à 3.

    Le CVE identifiant la faille 2.6.17-2.6.24 est CVE-2008-0600 (les autres ne touchent que 2.6.22-2.6.24).
  • # Question qui a son importance....

    Posté par . Évalué à 2.

    Je ne pourrai pas tester avant ce soir mais est ce que ce code permet de gagner les privilèges root de la machine (physique) depuis un vserver ou juste root dans le vserver ?
    • [^] # Re: Question qui a son importance....

      Posté par . Évalué à 2.

      Je me répond à moi même au cas ou ça intéresse quelqun...Après test l'utilisateur deviens root sur le vserver, c'était plutôt logique vu l'annonce mais bon vu que ça touchait aux fonctions pour les vserver ça m'inquiétait un peu ;)...
  • # EEEPC

    Posté par . Évalué à 2.

    En parlant de vulnérabilité, en voilà une qui risque de poser problème à de nouveaux linuxiens....

    http://www.vulnerabilite.com/asus-eee-pc-vulnerabilite-samba(...)
    • [^] # Re: EEEPC

      Posté par . Évalué à 0.

      Bonjour

      J'ai acheté hier cet Asus EEE

      Je sens que je vais remplacer vite fait Xandros par Linux Debian, parce que je connais bien Debian.

      Le système de mise à jour de ce Linux Xandros ne m'a pas plu du tout (je ne sais pas si la mise à jour de Samba était proposée, je ne m'y suis pas intéressé, et pour le moment j'ai prêté ce portable).

      J'ai voulu installer Miro, mais le clic sur le lien de DL pour Linux à été sans effet.

      Pour ma part, je sais que sous Debian, un aptitude install miro règlera cet obstacle.

      De même, je pourrai y installer kphotalbum....

      Enfin bref, je pourrai gérer cet ordinateur comme j'ai l'habitude de le faire, c'est à dire de manière conviviale :) une fois qu'il sera sous Linux Debian (un vrai Linux quoi).

      A bientôt
      G

Suivre le flux des commentaires

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