Hacker Newsnew | comments | ask | jobs | submitlogin
tptacek 467 days ago | link | parent

Calling YAML::load on attacker-controlled content in a Ruby app of any complexity is very bad news. As Ben and 'judofyr said: this is remote code execution.


aaronblohowiak 467 days ago | link

Is this because Yaml doesn't whitelist the classes for the objects that may be instantiated? They are allocated and then instance_variable_set'd so I'd be Very interested to learn how this poses a risk.

-----

tptacek 467 days ago | link

The people saying that they have POC code for remote code exec aren't making it up.

-----

aaronblohowiak 467 days ago | link

If I implied that I doubted them, then I failed to communicate my point effectively -- I am very curious about how to turn a class allocate + instance_variable_set into remote code exec. I see how you can create the arel objects for sqli, but not arbitrary ruby.

-----

jgeralnik 467 days ago | link

If you wait a couple of weeks you are much more likely to get an answer. Since all rails apps were vulnerable, most people who know how to execute arbitrary code are keeping silent for now.

-----

cmpb 466 days ago | link

It's not a full-on answer, but it should clear up a little bit about how this vulnerability is possible.

http://www.insinuator.net/2013/01/rails-yaml/

-----

regularfry 466 days ago | link

Sorry, would you mind clarifying? Any Ruby app? So a Sinatra app which happened to YAML.load would also be at risk?

-----

tptacek 466 days ago | link

Yes, if attackers controlled the content of the YAML message.

-----

Turing_Machine 465 days ago | link

In much the same way that letting attackers control the parameters to fork() would be a bad idea for a C program or letting attackers control the parameters to Runtime.exec() would be a bad idea for a Java program.

This is a Rails vulnerability, not a Ruby vulnerability.

-----




Lists | RSS | Bookmarklet | Guidelines | FAQ | DMCA | News News | Feature Requests | Bugs | Y Combinator | Apply | Library

Search: