Dwie poważne dziury w railsach

Dyskusje
1

W ostatnich dniach zostały znalezione i poprawione 2 poważne dziury w railsach. Nie będę powtarzał tego co napisał tenderlove, więc o szczegółach poczytajcie pod tymi linkami:

https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ
https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/t1WFuuQyavI

Z reguły nie wklejam takich informacji na forum, bo zainteresowani powinni śledzić rubyonrails-security, ale dziury są srogie, więc najlepiej powiadomić kogo się da i update’ować aplikacje do najnowszej wersji.

2

Jako, że już kilka osób miało mylne wrażenie, że na tą najpoważniejszą dziurę nie jest podatna większość aplikacji, to chciałbym sprostować jedną rzecz. Na dziurę w parserze XMLa jest podatna każda aplikacja w zagrożonych wersjach, bo railsy domyślnie przyjmują XML jako parametry.

I teraz najważniejsze:

Już zaczynają chodzić po sieci exploity, które pozwalają na wykonanie na serwerze dowolnego kodu

Jak chcecie sprawdzić, że rzeczywiście railsy domyślnie parsują XMLa, wystarczy stworzyć aplikację z prostą akcją w kontrolerze:

class FooController < ActionController::Base def index render :text => params.inspect end end
I wysłać takiego requesta:

curl -X POST -H "Content-Type: application/xml" -d "<foo>bar</foo>" -v http://localhost:3000/foo/index

W paramsach powinna być wartość “foo” => “bar”

Druga dziura też jest poważna, więc z tym też nie powinno się czekać. Co prawda nie można prosto zrobić exploita, na którego będzie podatna każda aplikacja, ale to tylko kwestia czasu zanim ktoś znajdzie gdzieś akcję, która wykonuje find_by_*, a to pozwala na jej wykorzystanie.

3

Czy ten exploit może występować też w Sinatrze?

4

Ten bug może występować w Sinatrze, jeśli korzystasz z AcitveRecorda/ActionPacka.

5

Tak jak krzyzak napisał, chociaż podejrzewam, że ActionPack + sinatra to rozwiązanie marginalne.

6

też nie bardzo jestem w stanie wymyśleć rozsądnego przypadku użycia sinatry z action packiem, ale tandem Sinatra + ActiveRecord jest już ciut powszechniejszą parą.

7

Chciałbym rozwinąć tutaj jeszcze wątek sinatry, bo w zasadzie do tej pory było kilka dziur w kilku różnych miejscach, więc można się pogubić.

Najpoważniejsza dziura, czyli ta w XML parserze nie powinna być problemem o ile ktoś nie używa ActionPacka do parsowania XMLa w sinatrze.

Kolejna dziura to możliwość przekazania hasha z opcjami do metod find_by_*. Np.

User.find_by_token(params[:token])

w tym przypadku można przekazać w params[:token] hasha, który będzie zinterpretowany jako opcje. Dziura może być wykorzystana, ale nie jest tak poważna jak inne, bo musi być spełnionych kilka założeń, więcej o tym tutaj: http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ Pomimo tego ActiveRecord powinen być zupdate’owany do najnowszej wersji - nie wiadomo czy to jest jedyny atak, który można przeprowadzić tym sposobem.

No i ostatnia dziura, find_by_* (także where() ) wersja druga:

User.find_by_token(['foo', nil])

Jeżeli atakującemu uda się przekazać tablicę z nilem, to może wykonać zapytanie, które sprawdzi obecność NULL w bazie tam gdzie tego byśmy nie chcieli. Tą dziurę jest dużo łatwiej wykorzystać niż poprzednią (prawdopodobnie większość resetów haseł i różnych innych rzeczy z tokenami jest podatnych), ale na to aplikacje sinatry powinny być odporne. Jednym ze sposobów wykorzystania tego w railsach jest przesłanie np. takich parametrów:

id[]=1;id[]=nil

które w railsach zamienią się na “id” => [1, nil]. Jeżeli chodzi o sinatrę, to na szczęście tam nie ma żadnego rzutowania, więc dostaniemy {“id”=>[“1”, “nil”]}.

Fix dla tego problemu jest w ActionPacku, dlatego tutaj update ActiveRecorda jest niepotrzebny i nic nie da. Warto sprawdzić też czy nie korzystacie z Rack::PostBodyContentTypeParser, w tym wypadku jesteście podatni na tą dziurę, bo tablica [1, null] w JSON, będzie sparsowana do [1, nil] w ruby.

8

Dzięki za wyjaśnienie sytuacji z Sinatrą

9

Oficjalne konto twitterowe Sinatry uważa że nie mają problemu:


:wink:

10

[quote=Tomash]Oficjalne konto twitterowe Sinatry uważa że nie mają problemu:


;)[/quote]
No i właściwie mają rację, jedyna dziura, którą da się wykorzystać bez dodatkowego middleware’u, to ta sprzed tygodnia: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/DCNTNp_qjFM (to ta, o której pisał Hongli Lai w poście podlinkowanym powyżej).

Jeżeli chodzi o te 2 nowe dziury, to rzeczywiście aplikacje na sinatrze są bezpieczne. Chyba, że ktoś korzysta z parsera JSON do paramsów wysłanych POSTem, ale nie wiem kto takich rzeczy używa szczerze mówiąc - większość aplikacji jakie widziałem nie łączyły nigdy w sinatrze paramsów z body.