Hacker News Reader

Comment by matthuggins | Hacker News Reader

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.

View on HN

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.

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.

It does now. But it didn't in versions <3.1.

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

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

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.h...

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.

Reply on news.ycombinator.com