Journal N05 4M15 135 H4CK3R5

Posté par .
Tags : aucun
14
17
sept.
2010
Mercredi a été publié un exploit sur Full Disclosure relatif à une faille du noyau Linux (sur la compatibilité 32 bits en architecture x86_64), ce qui n'est en soi pas bien original (pour Linux).

Mais je suis toujours ahuri de constater à quel point les farfouilleurs qui publient des exploits se comportent comme des script kiddies alors qu'à la vue du code (de manière superficielle, je l'admets), cela semble d'un niveau correct (pour du C).

En effet, Ac1db1tch3z, notre tête de vainqueur au pseudonyme si inventif, parsème son code de logs contenant des messages de killer tels que :

__pppp_tegddewyfg("$$$ bl1ng bl1ng n1gg4 :PppPpPPpPPPpP\n");
__pppp_tegddewyfg("!!! y0u fuq1ng f41l. g3t th3 fuq 0ut!\n");

Ensuite, son code est obfusqué à coups de #define et nom de structures/variables/fonctions incohérents et l33tesques.

Est-ce que la réalité est aussi ridicule que le décrit l'excellent (sic-zenitramesque) film Hackers, peuplée de nolifes puérils à la Zero Cool, Crash Override, Angelina Jolie Acid Burn et autres IvanLeF0u ?
  • # fatche ça va être dur d'attendre vendredi

    Posté par . Évalué à 10.

    rrraaa je suis trop faible \o/
    "c'est parceque n'importe quel gamin peux pirater linux"

    ça, c'est fait.
  • # Arf :/

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

    C'est d'un pathétique :/. Enfin bon, c'est bien d'avoir des codes exploits pour corriger ensuite des bugs, mais la manière quoi... Ou alors c'est juste du second degré ?
    • [^] # Re: Arf :/

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

      Est-il possible de cumuler un bon niveau en C et la maturité d'un pré-ado?
      Je pense que le lieu est idéal pour poser la question.....
      • [^] # Re: Arf :/

        Posté par . Évalué à 10.

        Vu que ça n'a pas empéché OpenBSD d'exister, ça doit être possible pour un petit programme en C !
    • [^] # Re: Arf :/

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

      Il semblerait que notre ami n'en est pas à son premier coup d'essai [1] et si je comprends bien il essaie aussi de se faire de l'argent de poche en vendant des exploits.

      [1] http://seclists.org/fulldisclosure/2010/Jun/302

      DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Arf :/

        Posté par . Évalué à 5.

        Il semblerait que notre ami n'en est pas à son premier coup d'essai
        C'est peut être son deuxième coup d'essai :)
    • [^] # Re: Arf :/

      Posté par . Évalué à 1.

      Grâce aux outils de détection de bug et de génération d'exploit, Jean-Kevin est descendu d'un niveau dans le monde informatique.

      Ce qui n'est pas plus mal, il passera moins de temps à lancer des floods où à jouer avec un botnet pour spamer son ex

      Bon après on peut débattre s'il faut publier ou ps les exploits de cette manière...
  • # il y a pire...

    Posté par . Évalué à 7.

    Vous connaissez tous Brad Spengler, expert en sécurité, auteur de grsecurity, auteurs de plusieurs exploits.
    Et bien récemment, un article sur LWN a évoqué un nouvel exploit dont il était l'auteur, mais cette fois c'est le délais de correction qui était souligné (près de 9 mois) : http://lwn.net/Articles/404043/
    En lisant l'article, on a l'impression qu'il y a eu un raté dans la gestion du rapport de Brad :
    Brad says that he first reported this problem in December, 2009, but got no response. More recently, he sent a note to Kees Cook, who posted a partial fix in response.

    Mais en fait, dans les commentaires de l'article, on s'aperçoit que ce n'est pas aussi simple.
    Greg Kroah-Hartman lui demande
    Was this sent to the security contact for the kernel? I just searched
    and could not find any notice sent to security@kernel.org from Brad
    during that month.

    If it was not sent there, where was it sent?


    Ce à quoi Brad répond :
    The context was I was already working with Ted on the ext4 bug, and since he was being responsive, chose to share some additional vulnerabilities with him.[...]With the general upstream attitude and handling of security bugs, on principle I don't email vendor-sec or security@.

    Donc, Brad n'a pas soumis l'exploit à la mailing-liste chargée de la sécurité, et n'en a fait part à Ted Ts'o que parce qu'il le sentait réactif.

    Encore pire, l'exploit avait déjà été corrigé dans grsec depuis un moment :
    > I've also got two local DoS mm-related bugs to be fixed if you'd like to
    > take a look at them. They exist in all 64bit kernels since 2.6.26 or
    > so. The first is an easy fix (we've fixed it in grsec for some time),
    > but the other one requires some more thinking and decision making (it's
    > memory exhaustion that causes a complete lockup of the machine -- and
    > the OOM killer is unaware of the memory because it's not
    > associated/accounted for by any task).


    Donc pour résumer, on a quelqu'un qui :
    - rapporte des exploits quand ça lui chante
    - ne les rapporte pas aux personnes concernées
    - corrige les failles concernées dans dans grsec

    Morale de l'histoire :
    - Brad en a sûrement d'autre en réserves, qu'il réserve pour plus tard (à la Sergey Bubka)
    - suivez les commits grsec, et vous verrez peut-être passer des patchs pour des failles non corrigées dans le noyau vanilla
    • [^] # Re: il y a pire...

      Posté par . Évalué à 9.

      C'est une blague?

      Moi aussi j'ai un compte LWN, je peux recopier l'article et les commentaires sans reflechir.

      Critiquer le comportement de Brad sans connaitre l'historique, c'est profondement debile.

      Entre les rapports de bugs ignores, les patchs sans attribution et les commits kernel dont les commentaires ont ete purges de toute historique et analyse de dangerosite, on comprend pourquoi il ne veut surtout pas perdre son temps avec ces gens la (dont certains le meprisent ouvertement)

      Apres on peut discuter du bien fonde de sa demarche (et il n'est certainement pas exempt de tout reproche, loin de la). Mais passer sous silence tout cette historique, c'est etre d'une extreme mauvaise foi.
  • # Et c'est un francophone...

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

    Confer ce bout de code :


    #define VERT "\033[32m"
    #define NORM "\033[0m"
    #define BANNER VERT"Ac1dB1tCh3z "NORM"VS Linux kernel 2.6 kernel 0d4y\n"
  • # Mauvaise attribution

    Posté par . Évalué à 2.

    /*
    * exploit for x86_64 linux kernel ia32syscall emulation (again)
    * rediscovered by ben hawkes
    * with help from robert swiecki and tavis ormandy
    *
    * original vulnerability discovered by Wojciech Purczynski
    *
    * original exploit by
    * Robert Swiecki <robert_at_swiecki.net>
    * Przemyslaw Frasunek <venglin_at_freebsd.lublin.pl>
    * Pawel Pisarczyk <pawel_at_immos.com.pl>
    *
    * kernel priv escalation code borrowed from spender
    *
    */

    Mais :

    /*

    Ac1dB1tch3z Vs Linux Kernel x86_64 0day

    Today is a sad day..

    R.I.P.
    Tue, 29 Apr 2008 / Tue, 7 Sep 2010

    a bit of history:
    MCAST_MSFILTER Compat mode bug found... upon commit! (2 year life on this one)

    author David L Stevens <dlstevens@us.ibm.com>
    Tue, 29 Apr 2008 10:23:22 +0000 (03:23 -0700)
    committer David S. Miller <davem@davemloft.net>
    Tue, 29 Apr 2008 10:23:22 +0000 (03:23 -0700)
    This patch adds support for getsockopt for MCAST_MSFILTER for
    both IPv4 and IPv6. It depends on the previous setsockopt patch,
    and uses the same method.

    Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
    Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    ------------------------------------------------------------

    Thank you for signing-off on this one guys.

    This exploit has been tested very thoroughly
    over the course of the past few years on many many targets.

    Thanks to redhat for being nice enough to backport it into early
    kernel versions (anything from later August 2008+)

    Ac1dB1tch3z would like to say FUCK YOU Ben Hawkes. You are a new hero! You saved the
    plan8 man. Just a bit too l8.

    PS:
    OpenVZ Payload / GRsec bypass removed for kidiots and fame whores. (same thing right ;))

    */

Suivre le flux des commentaires

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