2:50
9/1/2013

Jeśli twoja webaplikacja została stworzona przy pomocy frameworka Ruby on Rails to *NATYCHMIAST* zaaplikuj opublikowane właśnie patche — odkryto poważny błąd pozwalający atakującemu na zdalne wykonanie kodu. Dziura dotyczy wszystkich wersji Railsów z ostatnich 6 lat, zarówno w 2.x, jak i 3.x

Co może zrobić atakujący?

W skrócie, atakujący może zmusić webaplikację napisaną w Railsach do wykonania dowolnego kodu (np. system(“dowolna komenda”), a za błąd odpowiedzialny jest kod parsujący parametry XML typu Symbol i YAML (format serializacji danych).

Jednym z założeniem Railsów jest to, że użytkownik nie jest w stanie wstrzyknąć “złośliwego” symbolu do aplikacji… Tymczasem obiekt YAML pozwala na stworzenie instancji dowolnej klasy znajdującej się w aplikacji… Kod “!ruby/object:A\nfoo: 1\nbar: 1\n” stworzy obiekt klasy A i ustawi mu atrubuty foo i bar na odpowiednie wartości. Tworzyć można także obiekty bibliotek typu rack…

Podsumowując, atak polega na stworzeniu obiektu i przesłaniu go jako parametru do aplikacji. Przykładowe exploity na ten błąd krążą już po sieci, dlatego jak najszybciej należy zaktualizować Railsy do wersji 3.2.11, 3.1.10, 3.0.19, lub 2.3.15.

Rails

Rails Exploit Coding :)

Poniżej opis obu krytycznych podatności wykrytych przez Aarona Pattersona, a załatanych w najnowszych wersjach Ruby on Rails:

CVE-2013-0155 – Active Record i JSON parameter parsing

Błąd w parsowaniu JSON-a przy użyciu Active Record (wariant podatności CVE-2012-2660 orz CVE-2012-2694) pozwala atakującemu na wykonanie niespodziewanego zapytania do bazy typu IS NULL lub usunięcia klauzuli WHERE.

CVE-2013-0156 – Błędy w Action Pack

Błędy parsowania parametrów w Action Pack pozwalają na ominięcie uwierzytelnienia, wstrzykiwanie poleceń SQL, wstrzykiwanie dowolnego kodu, a także przeprowadzenie ataku DoS.

Railsy potrafią automatycznie rzutować stringi na inne typy danych. Niektóre z rzutowań (dotyczące Symbols, YAML) są niefortunne. Aby pozbyć się podatności można wyłączyć obsługę XML-a:

Railsy 3.x
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::XML)

Railsy 2.3
ActionController::Base.param_parsers.delete(Mime::XML)

Jeśli obsługa XML-a jest konieczna, należy wyłączyć Symbols i YAML:

Railsy 2.x (usunąć)
ActionController::Base.param_parsers[Mime::YAML] = :yaml

Railsy 3.x (dodać)
ActionDispatch::ParamsParser::DEFAULT_PARSERS.delete(Mime::YAML)
Railsy 3.2, 3.1, 3.0
ActiveSupport::XmlMini::PARSING.delete("symbol")
ActiveSupport::XmlMini::PARSING.delete("yaml")

Railsy 2.3
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('symbol')
ActiveSupport::CoreExtensions::Hash::Conversions::XML_PARSING.delete('yaml')

Na koniec polecamy lekturę wpisu Felixa, który obrazuje jak przy pomocy powyższych podatności wykonać atak SQL injection.


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

18 komentarzy

Dodaj komentarz
  1. Jak to zwykle bywa szybka poprawka wprowadza kolejne błędy: https://github.com/rails/rails/issues/8832

  2. Cóż, niektórzy apologeci RoR narzekają na inne języki (przy okazji rozpowiadając kłamstwa), a tu taka niespodzianka. Co z tego wynika? Że nie ma programów doskonałych, jeden jest lepszy w jednym, drugi – w drugim. Dlatego tym większe znaczenie ma kontrola własnego kodu, to, z czego korzystamy, a całą resztę należy wyłączyć.

    • Apologenci? Trole chyba. Doświadczeni programiści RoR i Rubiego są w pełni świadomi jak wygląda projekt w relacji do konkurencji. Bugi są wszędzie. Najważniejsze, że są łatane.
      Tak powstaje “dojrzałość” frameworku/kodu.

    • Racja, chociaż nie bardzo ma znaczenie “relacji do konkurencji”. Bardziej o jakość kodu mi chodzi, którą zrzuca się na RoR, bo “on wszystko za mnie załatwi” – takie słowa łatwo usłyszeć przy “plusach” RoR. To błędne podejście, o czym napisałem w niższym komentarzu.

  3. To, co podlinkowaliście z GitHuba to nie exploit, tylko kod sprzed 6 lat, który zawiera podatność. Do wczoraj w nocy eksploitów nie było, choć wyglądają na względnie proste do stworzenia (trzeba znaleźć w Railsach lub aplikacji klasę, która przy utworzeniu wykona dowolny kod i przesłać obiekt tej klasy zserializowany jako YAML w XMLu). Coś podobnego jak w PHP 2 lata temu ( http://media.blackhat.com/bh-us-10/presentations/Esser/BlackHat-USA-2010-Esser-Utilizing-Code-Reuse-Or-Return-Oriented-Programming-In-PHP-Application-Exploits-slides.pdf ) , tylko do PHP trzeba było kogoś klasy Stefana Essera, żeby to wyeksploitować, a w Railsach jest wyraźnie prościej.

  4. HD Moore pisze na Twitterze:

    For anyone working on the Rails bug, you can also abuse an obj=AnyClass.new; obj[x]=y code path through psyche’s !ruby/hash processor

  5. @Kenjiro Ruby on Rails to nie język tylko framework
    @Krzysztof Kotowicz wynika to z tego że ruby jest bardziej dynamiczny od php. Ruby pozwala na dynamiczne tworzenie klas z metodami a railsy wykorzystują tą właściwość do budowania modułów.

    Tak czy siak jest to dość mocny bug i trzeba będzie przeglądnąć wszystkie aplikacje. Railsy mają już parę latek i ciekawi mnie ile jest w nich jeszcze takich kwiatków.

    • Masz rację, tyle że nawet RoRowcy często reklamują swój framework porównując go z czystymi językami programowania jak PHP czy Python (pamiętam jak kilka lat temu denerwowały mnie te ich słynne reklamy na youtubie). W tym przypadku może nasz przedmówca miał na myśli właśnie takie przypadki?

    • Miałem bardziej na myśli to, iż RoR zachwala się jako wspaniały framework do czynienia cudów wszelakich, a to czyni z tego najpoważniejszą wadę – pomija się same wady frameworka, jako nieistniejące lub nieistotne.
      Moim zdaniem, powinno się traktować każdy framework (abstrahując już od RoR) jako osobny program, nad którym nie ma się kontroli, a co więcej, należałoby go poddać rozsądnemu audytowi przed użyciem.

      P.S. A odnośnie “apologetów”, to taki drobny przytyk względem tych, którzy chwalą swoje jako najlepsze, nie znając zbytnio wad lub je lekceważąc, gdyż odniosłem takie wrażenie wśród programistów RoR na forach, aczkolwiek nie mam zamiaru wszystkich wrzucać do jednego worka przecież.

  6. jakoś C istnieje od 40 lat i nie ma takich problemów jak te cudaczne języki dla IT-hipsterów.

    • Serio? To znaczy, serio chciałeś taki komentarz napisać? Nie dość, że porównujesz język z frameworkiem, do tego stricte tworzonym do pisania aplikacji web, niski z wysokim poziomem, to jeszcze hate. Wth?

    • c jest j. wysokiego poziomu.

    • @mao: ale niższego niż Ruby ;) (jeśli nie bawimy się w teoretyzowanie tylko między dwoma poziomami)

  7. A skąd tag “SQL-injection” ?

    • Cofam.
      //Nie mogłem usunąć komentarza.

  8. Odpowiedź Sinatry :)
    https://twitter.com/sinatra/status/289004380437487616

  9. […] użył opublikowanego przedwczoraj exploita na Ruby on Rails aby wytransferować Bitcoiny z giełdy Vircurex. Właściciel zapowiada zwrot BTC z własnej […]

  10. […] niedawno odkrytą podatność w Psych YAML będącą w rzeczywistości niczym innym jak dziurą odkrytą w Railsach na początku stycznia, ale o innym “podejściu” — w poprzednim patchu zapomniano załatać parsera JSON […]

Odpowiadasz na komentarz kravietz

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: