Salut,
DHH a annoncé aujourd’hui la sortie de Rails 1.15 qui
corrige un bug de sécurité dont il n’a pas encore révélé
la teneur.
Du coup, j’essaie d’investiguer un peu pour trouver
où était le problème.
rails-1.1.5
activerecord-1.14.4
actionpack-1.12.4
actionmailer-1.2.4
actionwebservice-1.1.5
РJean-Fran̤ois.
Bonsoir Jean-François,
a priori, le problème se situerait au niveau de la regexp qui gère la
route, dans le base.rb d’ActionPack.
Cela permettrait à un visiteur mal intentionné de faire du LOAD_PATH
injection.
Sur ce, je vous invite à mettre à jour avant que des petits malins ne
publie un script kiddy qui automatise l’exploit.
Cordialement,
Zifro :
a priori, le problème se situerait au niveau de la regexp qui gère la
route, dans le base.rb d’ActionPack.
action_controller/base.rb ? ya le rajout du code pour filtrer les logs
de sorte de ne pas faire apparaître les mots de passe dans les logs
mais c’est tout.
J’étais en train de regarder un bout de code, justement,
avec l’apparition de la méthode file_kinds, mais c’est dans
action_controller/routing.rb :
base[0, extended_root.length] == extended_root || base =~ %r{rails-[\d.]+/builtin}
Cela permettrait à un visiteur mal intentionné de faire du LOAD_PATH injection.
Ce serait en relation avec cette ligne là ?
base.match(/\A#{Regexp.escape(extended_root)}/*#{file_kinds(:lib) *
‘|’}/) || base =~ %r{rails-[\d.]+/builtin}
c’est dans la méthode ControllerComponent#safe_load_paths justement.
De toute façon, ça nécessite d’avoir une bonne connaissance
de routing.rb qui est loin d’être la partie de code la plus évidente.
(le file_kinds :app dans #traverse_to_controller est aussi intriguant)
Sur ce, je vous invite à mettre à jour avant que des petits malins ne
publie un script kiddy qui automatise l’exploit.
Pour ma part, j’ai pas encore compris comment un type extérieur
peut avec une bonne url tromper le système de routes de Rails
et manipuler le LOAD_PATH.
Pour l’instant c’est sûr, le script kiddy ne viendra pas de moi ! 
РJean-Fran̤ois.
2006/8/10, Guillaume Zifro DESRAT [email protected]:
exploitable dans des cas très rares (un peu comme pour évoquer
Cthlhu, face à l’Atlantique, la veille de Toussaint, avec des
tableaux de cire dans la main, et seulement quand telle
planète est n maison de ceci).
Sans invoquer les profonds et autres bestioles sympathiques,
ça m’a rappelé un post de Mauricio F. :
http://eigenclass.org/hiki.rb?ruby+symbols+memleak
Si, par un moyen ou un autre, une tierce personne arrive
à envoyer une URL au serveur, telle que cette adresse
arrive à tromper le système de routage au moment où
celui-ci recherche un nom de contrôleur dans l’url, et que
routing.rb génère un symbole (ou un module, #safe_load_paths
appelé par #attempt_load, lui même appelé par
#traverse_to_controller où il peut y avoir un Module.new
d’invoqué) ne correspondant à rien, avec une attaque de type
déni de service, tu dois pouvoir faire tomber un serveur.
Dans l’article de Fernandez, celui-ci évoquait de possibles
pbs de memory leak avec des symboles, mais plutôt
avec toute la partie méta-programmation de Rails.
Et le dernier message de DHH indique que <= 1.0 ainsi que
1.1.3 ne sont pas touchés, ce qui épaissit le mystère…
РJean-Fran̤ois.
Et le dernier message de DHH indique que <= 1.0 ainsi que
1.1.3 ne sont pas touchés, ce qui épaissit le mystère…
C’est bien plus excitant comme feuilleton de l’été que “Zodiaque” !
Pas de moi non plus !
On m’a mis le code en question (celui que tu as recopié dans ton mail)
sous
le nez, et rien ne m’a sauté aux yeux ; c’est une connaissance qui m’en
a touché
un mot hier soir sur IRC.
Moi le premier, je dois avouer que je ne vois pas bien comment
l’exploiter, étant donné
que les éléments qui pourraient être chargés via le LOAD_PATH sont
contrôlés par le
développeur. Bref, il me semble que si c’est bien ça la faille, c’est
exploitable dans des
cas très rares (un peu comme pour évoquer Cthlhu, face à l’Atlantique,
la veille de Toussaint, avec des tableaux de cire dans la main, et
seulement quand telle planète est n maison de ceci).
On verra bien ce que diront DHH et sa bande dans quelques jours
(semaines ?).
On en sait un peu plus par ici :
Mais ce qui ressort le plus de cette histoire, c’est la politique du
core team de Rails concernant les failles… et cela ne semble pas
plaire !
Bon, la version 1.1.5 a des défauts aussi… testez http://127.0.0.1:3000/cgi
Chez moi ça marche.
sous Webrick ou sous Mongrel juste "
Routing Error
Recognition failed for “/cgi”
"
Windows ??
Bon, la version 1.1.5 a des défauts aussi… testez
http://127.0.0.1:3000/cgi
Application stack error, et il vous faut alors relancer le serveur,
tous les autres appels ne fonctionneront pas.
Plus d’infos ici (dans les commentaires) :
http://www.ruby-forum.com/topic/76671
Un patch non officiel (en attendant la 1.1.6) pour ceux qui ont des
serveurs en production : changez la 276 du fichier <répertoire
ruby>/gems/1.8/gems/actionpack-1.12.4/lib/action_controller/routing.rb
pour :
base.match(/\A#{Regexp.escape(extended_root)}/*(?:#{file_kinds(:lib)
Je viens de le tester, l’appel à /cgi ne plante plus le serveur.
bonjour,
idem pour moi aussi " routing Error"
Sous Linux ( ubuntu)
Mathieu C. a écrit :
Merci DHH
Le 10 août 06 à 17:43, fredix a écrit :
Mmmh…
Mathieu, Philippe, Frédéric me soumettait une idée : avez-vous mis Ã
jour vos applications (rake rails:update à la racine de votre
application Rails ou changement manuel de la version à utiliser dans
environment.rb) ?
pour ma part, non
Guillaume “Zifro” DESRAT a écrit :
2006/8/10, Guillaume Zifro DESRAT [email protected]:
Bon, la version 1.1.5 a des défauts aussi… testez
http://127.0.0.1:3000/cgiApplication stack error, et il vous faut alors relancer le serveur,
tous les autres appels ne fonctionneront pas.
Ca me donne un :
TypeError
superclass mismatch for class Cookie
Ensuite le site m’affiche :
Application error
Change this error message for exceptions thrown outside of an action
(like
in Dispatcher setups or broken Ruby code) in public/500.html
donc planté, obligé de relancer le serveur webrick.
oups, dsl, je suis hors sujet la 
en fait je suis toujours en 1.1.4
philippe a écrit :
http://127.0.0.1:4500/cgi (Mongrel)
Mongrel tourne toujours.
http://127.0.0.1:3001/cgi (WeBrick)
Webrick est satellisé…
Mathieu, Philippe, Frédéric me soumettait une idée : avez-vous mis à
jour vos applications (rake rails:update à la racine de votre
application Rails ou changement manuel de la version à utiliser dans
environment.rb) ?
Non, merci du conseil, c’est chôse faite.
Rails -v c’est pas suffisant.
J’ai donc bien : "
http://127.0.0.1:4500/cgi (Mongrel)
TypeError
superclass mismatch for class Cookie
"
http://127.0.0.1:3001/cgi (WeBrick)
TypeError
superclass mismatch for class Cookie
2006/8/10, Guillaume Zifro DESRAT [email protected]:
Bon, la version 1.1.5 a des défauts aussi… testez
http://127.0.0.1:3000/cgiApplication stack error, et il vous faut alors relancer le serveur,
tous les autres appels ne fonctionneront pas.
Par contre en prod avec apache2 + fcgid j’ai bien l’erreur mais
apparemment
pas de plantage.
Oui, je suis sous Windows XP au bureau, c’est là que j’ai testé.
Et le problème n’affecte que WEBrick apparemment… enfin, c’est tout
ce qui est remonté pour l’instant.
Ouvrons l’oeil.
Et le bon.
Rails 1.1.6 vient de sortir …
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs