Injection SQL sur toutes les versions de Ruby on Rails

Posté par Florent Zara (site web personnel, Mastodon) le 03 janvier 2013 à 18:58. Édité par Bruno Michel, Benoît Sibaud, baud123 et rootix. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

jan.

2013

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.


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.

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

Aller plus loin

Annonce de la faille d'injection SQL dans RoR (327 clics)
Ruby on Rails (32 clics)
Divulgation initiale de la faille (92 clics)
Explication complémentaire sur la faille (142 clics)

# Merci

Posté par ariasuni le 03 janvier 2013 à 21:45. Évalué à 6.

pour le xkcd!

Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Merci
  
  Posté par Amine "nh2" Brikci-Nigassa (site web personnel) le 04 janvier 2013 à 20:56. Évalué à 3. Dernière modification le 04 janvier 2013 à 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 Adrien Dorsaz (site web personnel, Mastodon) le 03 janvier 2013 à 23:00. É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 Adrien Dorsaz (site web personnel, Mastodon) le 03 janvier 2013 à 23:06. É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 Oles le 04 janvier 2013 à 01:35. É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."
    - [^] # Re: Comment fonctionne le patch 3.2
      
      Posté par Adrien Dorsaz (site web personnel, Mastodon) le 04 janvier 2013 à 13:00. Évalué à 1.
      
      Merci, c'est plus claire maintenant.
# impacter-impactant

Posté par Bayet Thierry le 04 janvier 2013 à 09:53. É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 flagos le 04 janvier 2013 à 11:03. É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 boq le 04 janvier 2013 à 11:57. É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 Florent Zara (site web personnel, Mastodon) le 04 janvier 2013 à 11:43. É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)
  - [^] # Re: impacter-impactant
    
    Posté par Burps le 04 janvier 2013 à 15:36. Évalué à 1.
    
    Tant qu'on y est: "je l'admets".
# Précision

Posté par piglop le 04 janvier 2013 à 14:02. É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 Gof (site web personnel) le 09 janvier 2013 à 16:11. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.