Le projet PaX compromis

Posté par  (site web personnel) . Modéré par rootix.
Étiquettes :
0
7
mar.
2005
Sécurité
PaX est un projet visant à apporter à Linux des moyens de prévenir et/ou de minimiser l'impact des failles donnant accès à l'espace d'adressage d'une tâche, comme les dépassements de tampon (buffer overflow), les format string attacks, etc. Il est une partie importante de grsecurity, qui fournit un ensemble d'améliorations liées à la sécurité pour Linux (protection renforcée des chroot , RBAC, etc.).

Le projet a annoncé le 4 mars la présence d'une faille majeure dans le code même de PaX, permettant d'obtenir à un utilisateur simple de gagner des droits plus importants sur le système, voire des droits administrateurs. Cette faille est exploitable localement, mais une exploitation à distance semble peu probable.

Une version mise à jour du patch est bien sûr disponible sur le site de PaX, ainsi que la version 2.1.2 de grsecurity qui inclut le correctif. Dans l'urgence,

# echo "0 0" > /proc/sys/vm/pagetable_cache

...permet d'éviter le principal vecteur d'exploitation potentiel.

Les auteurs de PaX ont par ailleurs déclaré qu'au vu de la gravité de la faille et pour d'autres raisons, le développement de celui-ci serait arrêté au 1er avril 2005. Brad Spengler, un des auteurs de grsecurity, s'est cependant porté volontaire pour reprendre le flambeau.

NdM : merci à mmenal pour avoir contribué à la news. Une des fonctionnalités majeures de PaX est la protection contre les dépassements de tampon. Ce type de faille consiste à faire écrire par un programme des données en des emplacements non légitimes, notamment par dessus son propre code (ou toute autre donnée déjà accessible en écriture ET en exécution).

PaX remédie à ce dernier cas en interdisant qu'une page soit à la fois accessible en écriture et en exécution. Cette technique, baptisée NOEXEC, est quelque peu complexe sur IA-32, où le fait d'interdire l'exécution d'une page ne peut être implémenté que de façon logicielle (seuls les AMD64, et quelques Pentiums peuvent le faire au niveau du matériel, ils appellent respectivement cela NX ou EVP et XD). C'est notamment l'activation de cette fonctionnalité qui permet d'utiliser la faille découverte récemment.

PaX permet également de rendre aléatoire la position en mémoire du code d'une application ou d'une bibliothèque, afin de rendre l'écriture de shellcodes plus difficile. L'activation de cette fonctionnalité permet également d'utiliser la faille.

Pour des raisons évidentes, de nombreux projets utilisent PaX, parmi lesquels Adamantix (Trusted Debian) et Hardened Gentoo.

Les détails techniques autour de cette faille, de son exploitation ainsi que de la façon dont elle a été corrigée ne sont pas encore publics.

Aller plus loin

  • # Mauvaise nouvelle

    Posté par  . Évalué à 6.

    Plus que la faille, on ne peut empêcher l'erreur humaine... L'abandon du projet est plus problématique, en effet PaX propose une solution efficace pour se protéger de la majoritée des attaques, avec une perte de performances faible.
    Espérons que l'auteur reviendra sur sa décision.

  • # Spengler away

    Posté par  . Évalué à -2.

    > Brad Spengler, un des auteurs de grsecurity, s'est cependant porté volontaire pour reprendre le flambeau.

    Je suis un peu étonné car je le vois souvent sur la ML
    Ou alors j'ai fumé des GNUs en plastiques ?!

    • [^] # Re: Spengler away

      Posté par  . Évalué à 5.

      Subject: [grsec] grsecurity 2.1.3 released for 2.4.29/2.6.11 *CRITICAL UPDATE FOR RBAC USERS*
      From: "Brad Spengler" <spender AT grsecurity POINT net>
      Date: Mon, March 7, 2005 15:46
      To: grsecurity AT grsecurity POINT net


      grsecurity 2.1.3 has been released to fix a number of problems found
      during a routine audit of grsecurity. Changes in this release include
      allowed gradm -u for non-root users in a no-authentication special role,
      addition of a missing ptrace hook on amd64, fixed hidden file check that
      takes subject inheritance into account, unification of the mmap hook so
      it no longer requires a per-arch component, and the breakup of the "O"
      subject flag into "O" and "t", where "O" now means to allow writable
      library loads for the process, while "t" allows a process to ptrace any
      task. The "t" mode should be used sparingly in combination with the
      no-ptrace object flag. A bug in PaX that causes a SIGBUS in a task when
      SEGMEXEC is enabled but MPROTECT is disabled has been fixed in this
      release as well.
      During the audit, a critical vulnerability was found in the RBAC system
      that effectively gave every subject the "O" flag, allowing a root user
      for instance to gain the privileges of any other process through
      LD_PRELOAD or ptrace. If you have already upgraded to 2.1.2 and use the
      RBAC system, I strongly urge you to upgrade to 2.1.3. To ensure that
      problems like this won't occur in the future, I will be developing an
      extensive regression test suite for the RBAC system similar to the one
      that exists already for non-RBAC features.

      Sorry about the timing of this release, but the vuln I discovered is
      quite serious, and I'm hoping to catch the people who haven't updated
      their machines to 2.1.2 yet due to it being released over the weekend.

      -Brad

    • [^] # Re: Spengler away

      Posté par  . Évalué à 3.

      Je me répond à moi-même parce que j'avais croiser un peu les données :

      mainteneur PaX != Brad Spengler

      voila :-)
      désolé pour le bruit :)

  • # Lien

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

    manque dans les liens de la news, la page de pax:

    http://pax.grsecurity.net/(...)

    (c'est grsec qui host pax maintenant et plus pageexec.virtualave.net )

  • # Kernels touchés...

    Posté par  . Évalué à 7.

    Seuls les kernels dont les options SEGMEXEC et/ou RANDEXEC sont activés sont vulnérables à ce problème.
    Pour savoir si votre kernel est touché, un petit grep sur le .config pour être sur.

    Par ailleurs, PaX est inclus dans Grsecurity, donc penssez à vérifier. Dans Grsec, ces deux options sont activées avec le niveau "High" de sécurité (pas avec Low ni Medium) ou en "Custom" si vous les avez activés vous même.

    Dans le doute recompillez votre kernel en désactivant ces deux options. Le # echo "0 0" > /proc/sys/vm/pagetable_cache n'étant qu'une solution temporaire et qui ne résouds pas tous les problèmes.

  • # 1er avril

    Posté par  . Évalué à 8.

    > Les auteurs de PaX ont par ailleurs déclaré qu'au vu de la gravité de la faille et pour d'autres raisons, le développement de celui-ci serait arrêté au 1er avril 2005.

    C'est le poisson d'avril le plus précoce que j'ai jamais vu !
    ~ ->[]....

  • # Pof, faille refermée

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

    Faille annoncée le 4 Mars, refermée le 7 mars (ou le 5 ?) :
    NOTE: all versions for 2.4 before 2005.03.05 have a privilege elevation bug, you must update as soon as possible.

    http://pax.grsecurity.net/(...)

    Encore une fois, il faut féliciter la réactivité du logiciel libre !

    @+ Haypo

Suivre le flux des commentaires

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