Journal Faille de sécurité critique dans Joomla 1.5

Posté par  .
Étiquettes : aucune
0
13
août
2008
Bonjour à tous,

La faille a été rendue publique hier et ne concerne que les versions 1.5 du CMS.

Une personne mal intentionnée peut modifier le mot de passe de l'admin en quelques secondes, sans compétence particulière.

Liens:
Le blog officiel (explications et correction) http://developer.joomla.org/security/news/241-20080801-core-(...)
Les détails en français ici http://www.tux-planet.fr/faille-de-securite-dans-joomla-15x-(...)
Les updates là http://www.joomlafacile.com/telechargements/Patches-de-mise-(...)

  • # Erf

    Posté par  . Évalué à 5.

    En effet, c'est gros.
    Je viens de tester sur un site trouvé sur google. Je suis actuellement face à un formulaire pour réinitialiser de mot de passe administrateur d'un site commercial...

    Bon, je vais pas le faire, j'suis pas un salaud. C'était juste histoire de tester.

    • [^] # Re: Erf

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

      Il semblerait que la correction dans la 1.5.6 soit :
      [code]
      if(strlen($token) != 32) {
      $this->setError(JText::_(’INVALID_TOKEN’));
      return false;
      }
      [/code]

      Cela me semble très bête parce qu'un simple '''''''''''''''''''''''' (32 fois ') permettrait de continuer à utiliser la faille.

      Enfin, ça ne me réconcilie pas avec Joomla parce ce que j'estime que ce genre d'erreur est vraiment évitable. (Bordel, on escape tous les formulaires qu'on reçoit avant de faire une requête quand même)

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Erf

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

        Mouais.

        C'est le genre de choses qui arrive souvent dans les CMS qui ont été commencés y a des années, avec du code pas du tout objet, sans tests unitaires ni fonctionnels...

        • [^] # Re: Erf

          Posté par  . Évalué à 7.

          qui ont été commencés y a des années
          Je ne vois pas le rapport :-)

          avec du code pas du tout objet
          Là non plus.

          sans tests unitaires ni fonctionnels
          Là par contre, je vois :-)

          • [^] # Re: Erf

            Posté par  . Évalué à -1.

            Si si moi je le vois le rapport, railers en vues (:

            Allez tous vous faire spéculer.

      • [^] # Re: Erf

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

        Ça doit pas être que ça parce que en mettant '''''''''''''''''''''''''''''''' (32*') je n'ai plus le formulaire Réinitialiser votre mot de passe. D'ailleurs, je me demande pourquoi ceci ne marche pas...

        • [^] # Re: Erf

          Posté par  . Évalué à 0.

          Peut-être parce que ça crée un erreur de syntaxe SQL ? En plus, ça fait au final un nombre impair de "'" (voir le 2e lien pour le code).
          Peut-être qu'un :
          ';xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
          marchera ?...

          • [^] # Re: Erf

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

            Non, ça marche pas non plus. Ni '//xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

      • [^] # Re: Erf

        Posté par  . Évalué à 1.

        Bordel, on escape tous les formulaires qu'on reçoit avant de faire une requête quand même

        Il est primordial d'utiliser une fonction de validation et d'épuration des données saisies par l'utilisateur, avant de les soumettre à une base de données.

        • [^] # Re: Erf

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

          Oui, mais bon, ça me gonfle aussi les épuration à la con, genre interdire les mots de passe de plus de 8 caractère, ou les chiffres, ou les accents, ou les caractères spéciaux (exemples vécus, sur des sites "importants", et le plus rigolo est quand même un site de purs geeks programmeurs comme Sourceforge : "passwords should contain only letters and numbers. Inclusion of other characters in your password may result in inability to access some SourceForge.net systems" suivi, si tu ne suis pas le "may", à croire que je ne comprend plus l'anglais ce que je comprend comme un conseil n'étant alors pas un conseil, de "Please use only letters (A-Z, a-z) and numbers (0-9) in your password" si tu dévies de la recommandation. Super le mot de passe fiable...)

          Bref, il est primordial d'utiliser une fonction de validation et d'épuration des données saisies par l'utilisateur correcte et non limitative.

          • [^] # Re: Erf

            Posté par  (Mastodon) . Évalué à 0.

            euh autant une limitation du nombre de caractère est chiant, autant le fait de ne pas autorisé tous les caractères n'empêche pas de créer des mots de passe fiables. Il suffit qu'ils soient suffisemment long et non proches de nom communs.

      • [^] # Re: Erf

        Posté par  . Évalué à 7.

        J'ai regardé le code de la faille, ça n'a rien à voir avec de l'échappement. En mettant # à la place de ' ça marche aussi, et en laissant une chaîne vide ça marche également (à condition de désactiver javascript dans le navigateur).

        Les requêtes SQL sont correctement échappées dans Joomla et les saisies de formulaires sont vérifiés.
        Le problème est que le fameux code qui être saisi est normalement composé que de lettres et de chiffres. Joomla nettoie ce code en supprimant tout ce qui n'est pas lettre ou chiffre puis effectue un échappement.

        Le déroulé de la faille est le suivant:
        o saisie par exemple du token: ###{{}{}
        o nettoyage par Joomla: le token devient une chaîne vide
        o échappement par Joomla de la chaîne vide
        o Le code SELECT id FROM #__users WHERE block = 0 AND activation = '.$db->Quote($token) devient SELECT id FROM jos_users WHERE block = 0 AND activation = ''
        o La colonne activation de la table SQL est vide pour un utilisateur n'ayant pas demandé la réinitialisation de son mot de passe, d'où le bug et son code de correction.

        Donc oui, la faille aurait du être évitée, mais ce n'est pas non plus aussi trivial que ça.

    • [^] # Re: Erf

      Posté par  . Évalué à 2.

      Pour ma culture, il y a vraiement des applis php qui n'ont pas/peu de faille de secu ?

      Parce que bon on retrouve toujours le même genre d'erreur ; pas de validation des données entrantes...

      • [^] # Re: Erf

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

        PHP est très souvent accompagné de MySQL. Or MySQL est mal configuré par défaut : tout est autorisé, même LOAD_FILE et INTO OUTFILE. De plus, échapper une chaîne d'octets (PHP ne gère pas Unicode) pour la passer à MySQL n'est pas toujours évidant car le charset du site web peut-être différent de celui de la base de données (il existe mysql_escape_string et mysql_real_escape_string ...) :
        http://www.abelcheung.org/advisory/20071210-wordpress-charse(...)

        Pour info, d'autres failles liées à Unicode :
        http://www.haypocalc.com/blog/index.php/2008/01/26/124-faill(...)

        Je pense que n'importe quelle application utilisant des fonctions haut niveau pour gérer l'accès à la base de données (MySQL ou autre), peut se protéger des injections SQL.

        Euh... on parlait de PHP ? Ah mince.

        Je pense que le « problème » de PHP est qu'il est trop facile à utiliser et que n'importe quel quidam sans aucune notion de sécurité peut écrire et publier son site web. La majorité des développeurs préfèrent réécrire leur CMS troué que d'utiliser un CMS testé et éprouvé.
        http://blog.halon.org.uk/geek/debian/security/php_clippy.htm(...)

        Au moins avec le C, on n'a pas ces problèmes.

        • [^] # Re: Erf

          Posté par  . Évalué à 0.


          Au moins avec le C, on n'a pas ces problèmes.


          Tu as parfaitement raison ! Regarde le noyau, dont une bonne partie est écrite en C par des débutants qui ne font aucun test unitaire, on n'y a jamais découvert la moindre faille.

          La morale est que toute application a des failles.

          • [^] # Re: Erf

            Posté par  . Évalué à 4.

            Je crois que c'était ironique.

Suivre le flux des commentaires

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