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 :
<
< def file_kinds(kind)
< ((@file_kinds ||= []) << kind).uniq! || @file_kinds
< end
<
235d230
< file_kinds :app
276c271
<
base.match(/\A#{Regexp.escape(extended_root)}/*#{file_kinds(:lib) *
‘|’}/) || base =~ %r{rails-[\d.]+/builtin}
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.