5 ms·

Can someone explain the security issue in more detail? Is it that I can supply Symbols (and other Ruby objects) in my YAML, which normally can't be included in

Can someone explain the security issue in more detail? Is it that I can supply Symbols (and other Ruby objects) in my YAML, which normally can't be included in JSON? That seems to be the basis of it, but I'm looking for more info if available.

jmillikin 14y ago
The Rails YAML parser allows execution of arbitrary Ruby code, by design. If an attacker can figure out how to get input into the YAML parser, they win.
- tveita 14y ago
  That's awful. This seems to be something of a theme with RoR. XML parsers that parse YAML, JSON parsers that parse YAML, YAML parsers that parse Ruby... Why would they let that mess near user input? I thought Ruby included a proper JSON parser now.
  - knowtheory 14y ago
    It does now. But it didn't in versions <3.1.
- postmodern_mod3 14y ago
  YAML does not allow execution of arbitrary Ruby code. Some YAML types allow specifying a custom class, which the Psych YAML parser (default in Ruby 1.9) will call the initialize or []= methods. If you can find a class that eventually evals() input passed to initialize or []=, then you win. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
postmodern_mod3 14y ago
Checkout the lengthy write-up for the original vulnerability. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
- matthuggins 14y ago
  Thanks for the link, but it looks like that's for CVE-2013-0156 and CVE-2013-0155. This HN post is about CVE-2013-0333. It does look like there's a newer blog post about this issue though: http://ronin-ruby.github.com/blog/2013/01/28/new-rails-poc.html http://ronin-ruby.github.com/blog/2013/01/28/new-rails-poc.h...
  - postmodern_mod3 14y ago
    Took a while to write a new blog post. Still, CVE-2013-0333 relies on the same YAML deserialization technique as CVE-2013-0156, so all the previous information is still relevant.

jmillikin 14y ago

The Rails YAML parser allows execution of arbitrary Ruby code, by design. If an attacker can figure out how to get input into the YAML parser, they win.

tveita 14y ago
That's awful. This seems to be something of a theme with RoR. XML parsers that parse YAML, JSON parsers that parse YAML, YAML parsers that parse Ruby... Why would they let that mess near user input? I thought Ruby included a proper JSON parser now.
- knowtheory 14y ago
  It does now. But it didn't in versions <3.1.
postmodern_mod3 14y ago
YAML does not allow execution of arbitrary Ruby code. Some YAML types allow specifying a custom class, which the Psych YAML parser (default in Ruby 1.9) will call the initialize or []= methods. If you can find a class that eventually evals() input passed to initialize or []=, then you win. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html

postmodern_mod3 14y ago

Checkout the lengthy write-up for the original vulnerability. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html

matthuggins 14y ago
Thanks for the link, but it looks like that's for CVE-2013-0156 and CVE-2013-0155. This HN post is about CVE-2013-0333. It does look like there's a newer blog post about this issue though: http://ronin-ruby.github.com/blog/2013/01/28/new-rails-poc.html http://ronin-ruby.github.com/blog/2013/01/28/new-rails-poc.h...
- postmodern_mod3 14y ago
  Took a while to write a new blog post. Still, CVE-2013-0333 relies on the same YAML deserialization technique as CVE-2013-0156, so all the previous information is still relevant.