Injection SQL sur toutes les versions de Ruby on Rails

Posté par (page perso) . Édité par Bruno Michel, baud123, Benoît Sibaud et Christophe Guilloux. Modéré par patrick_g. Licence CC by-sa
Tags :
25
3
jan.
2013
Sécurité
   
Les développeurs de Ruby on Rails (aka RoR, un framwork de développement web open source populaire et basé sur Ruby) viennent d'émettre une alerte concernant une faille de sécurité de type injection SQL touchant toutes les versions de Ruby on Rails. Selon l'annonce, la faille se situe dans l'interface de requêtage d'ActiveRecord et plus précisément dans la manière dont les dynamic finders extraient les options des paramètres de méthodes. Un paramètre peut être utilisé en tant que scope et en manipulant ce dernier, il devient possible d'injecter du SQL. Des appels tels que Post.find_by_id(params[:id]) sont vulnérables. Nous vous laissons consulter l'annonce pour plus de détails. Logo RoR

Les mainteneurs ont sorti des nouvelles versions hier – 3.2.10, 3.1.9 and 3.0.18 – corrigeant le problème et il est fortement recommandé de mettre à jour dès que possible. Pour ceux qui ne peuvent se permettre une mise à jour, des patches sont aussi disponibles pour les branches supportées (3.1.x et 3.2.x), mais aussi des branches plus anciennes et non supportées officiellement (3.0 et 2.3). Dans ce dernier cas, il faut vraiement mettre à jour car les correctifs de sécurité ne sont pas garantis à l'avenir.

LinuxFr.org, qui, rappelons-le, est basé sur RoR, est déjà passé en 3.2.10 !

Le XKCD réglementaire : Exploits of a Mom

  • # Merci

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

    pour le xkcd!

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Merci

      Posté par (page perso) . Évalué à  3 . Dernière modification : le 04/01/13 à 20:57

      Oui, merci, j'en ai ri aux larmes ! "Little Bobby Tables" XD

      GNU's Not Unix / LINUX Is Not Unix Xernel

  • # Comment fonctionne le patch 3.2

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

    Hello!

    Je viens de regarder le patch 3.2 et j'ai vu qu'il consistait en la modification d'une ligne (le reste est l'ajout de tests) :

    -          options = arguments.extract_options!
    +          options = if arguments.length > attribute_names.size
    +                      arguments.extract_options!
    +                    else
    +                      {}
    +                    end
    +
    
    

    Je ne connais pas ruby, mais je ne comprends pas ce que la condition vérifie, pouvez-vous m'éclairer ? Pour moi, la condition devrait être comme ceci plutôt :

    -          options = arguments.extract_options!
    +          options = if arguments.length <= attribute_names.size #donc si le nombre d'argument est inférieur ou égale au nombre d'attribut on accepte les arguments
    +                      arguments.extract_options!
    +                    else
    +                      {}
    +                    end
    +
    
    
    • [^] # Re: Comment fonctionne le patch 3.2

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

      Mmmhhh, je viens de lire le Sujet du patch et ils indiquent bien :

      Subject: [PATCH] CVE-2012-5664 options hashes should only be extracted if
      there are extra parameters

      Donc, le patch fait bien ce qu'il dit et je n'ai donc pas compris comment fonctionne cette injection SQL.

      • [^] # Re: Comment fonctionne le patch 3.2

        Posté par . Évalué à  6 .

        - options = arguments.extract_options!
        + options = if arguments.length > attribute_names.size
        +             arguments.extract_options!
        +           else
        +             {}
        +           end
        
        

        Les fonctions find_by_* peuvent recevoir au minimum deux arguments (mais n'en requièrent qu'un au minimum), par exemple find_by_name peut recevoir deux arguments, le nom recherché et des options : find_by_name('Linus', :limit => 1) ou un seul argument : find_by_name('Linus').

        Le problème est que si on ne donne que les options comme argument : find_by_name(:limit => 1) ça fonctionne quand même, du coup le patch n'extrait les options que si il y a les autres arguments passés.

        arguments.length retourne le nombre d'argument donnés (facile).
        attribute_names.size retourne le nombre d'attributs de la recherche (find_by_name => 1, find_by_name_and_karma => 2)

        Donc pour traduire le code : arguments.length > attribute_names.size : si le nombre d'arguments donnés est strictement supérieur au nombre d'attributs de la recherche alors on extrait les options (sinon, pas d'options).

        "Never trust a statistic you haven't faked yourself."

  • # impacter-impactant

    Posté par . Évalué à  5 .

    Réellement mare de ce mot. Un avion a reçu un impact de balle,mais: «une faille de sécurité de type… touchant toutes les versions de …».

    Non seulement, c'est plus court (de une lettre, je l'admet), mais c'est plus clair et français. La langue doit évoluer, pas régresser.

    Tous mes meilleurs vœux pour cette année 2013.

    • [^] # Re: impacter-impactant

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

      Wé mais "impact" ca fait plus pro, genre "Les experts" de la sécurité, tu imagines tout de suite le hacker qui code dans son shell avec des lunettes de soleil et tout ca.

      • [^] # Re: impacter-impactant

        Posté par . Évalué à  10 .

        qui code dans son shell avec des lunettes de soleil

        J'ai essayé mais on voit rien et on fait de la merde.

        Le dernier qui à sorti du code important comme ça s'appelle Lennart Poettering je crois.

        ♫ vendrediiii ♩♫ je m'en fouuuus ♩♬ j'ai le droiiiiiit ♪♫

    • [^] # Re: impacter-impactant

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

      Voilà, c'est fixécorrigé. Ca ne vaut pas la peine de se mettre dans tous ses états pour ça !

      Non seulement, c'est plus court (de une lettre, je l'admet)

      Ne pas oublier l'apostrophe : « (d'une lettre,… », c'est correct et français. La langue doit évoluer, pas régresser (Tout comme si il s'écrit s'il)

  • # Précision

    Posté par . Évalué à  4 .

    Dans l'explication complémentaire (dans les liens), il est précisé qu'un simple Post.find_by_id(params[:id]) ne suffit pas à déclencher la faille. Il faut passer un Hash qui a des symboles comme clés, alors que params utilise des chaines comme clés.

    Ça limite énormément la portée de la faille, car les find_by_* sont la plupart du temps justement utilisés avec params.

    Là où c'est plus problématique, c'est que la gem authlogic passe justement un Hash avec des symboles lors de l'authentification. Mais même dans ce cas, pour exploiter le bug il faut connaitre la clé secrète du site web pour forger ses propres cookies.

  • # Et encore une

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

    La faille annoncée dans cette dépêche n'est exploitable que sous certaines conditions qui ne sont pas si souvent réunies.

    Mais aujourd'hui à été annoncé une nouvelle faille bien plus grave:
    http://arstechnica.com/security/2013/01/extremely-crtical-ruby-on-rails-bug-threatens-more-than-200000-sites/

    Les explications:
    http://www.insinuator.net/2013/01/rails-yaml/

Suivre le flux des commentaires

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