Its been quite a January so far, and we aren't even half way through!
Earlier this week (Prior to the January 10th, 2013 Java 0day), another major remote code execution vulnerability was disclosed which effects Ruby on Rails implementations 2.x and 3.x.
Summary Here: http://threatpost.com
So far, a Metasploit module and POC exploit code have been released. The SQL injection vulnerability is nicely summarized here:
!ruby/object:Arel::Nodes::SqlLiteral
A trio of vulnerabilities exist, JSON, XML [Parsing], and Remote Code Execution. For more information see the link here: http://ronin-ruby.github.com/blog. The root of these vulnerabilities lies in the way in which Rails parses YAML input (user-controlled).
If you want an in depth break down of the functionality of the RoR vulnerability:
http://www.insinuator.net/2013/01/rails-yaml/
For a tl:dr
1. The XML case calls Hash.from_xml() passing the raw POST body as argument
2. The YAML string “”— !ruby/object:A\nfoo: 1\nbar: 1\n” will create an object instance of class A and set the object attributes @foo and @bar to the value 1. This means that an attacker can create instances of all classes defined in the targeted Rails application.
3. ^^ All basic Ruby classes are included, meaning this vulnerability is quite broad.
4. The YAML parser used by Ruby supports the serialization and deserialization of arbitrary data types. This includes Symbols and also arbitrary Objects.
5. SQLi (in the form of the arel object) is probably only the first of many different ways to exploit this, as it is essentially remote code execution.
6. Validate input. Seriously.
Mitigation
Upgrade Rails to one of the following releases: 3.2.11, 3.1.10, 3.0.19 or 2.3.15.
Earlier this week (Prior to the January 10th, 2013 Java 0day), another major remote code execution vulnerability was disclosed which effects Ruby on Rails implementations 2.x and 3.x.
Summary Here: http://threatpost.com
So far, a Metasploit module and POC exploit code have been released. The SQL injection vulnerability is nicely summarized here:
!ruby/object:Arel::Nodes::SqlLiteral
A trio of vulnerabilities exist, JSON, XML [Parsing], and Remote Code Execution. For more information see the link here: http://ronin-ruby.github.com/blog. The root of these vulnerabilities lies in the way in which Rails parses YAML input (user-controlled).
If you want an in depth break down of the functionality of the RoR vulnerability:
http://www.insinuator.net/2013/01/rails-yaml/
For a tl:dr
1. The XML case calls Hash.from_xml() passing the raw POST body as argument
2. The YAML string “”— !ruby/object:A\nfoo: 1\nbar: 1\n” will create an object instance of class A and set the object attributes @foo and @bar to the value 1. This means that an attacker can create instances of all classes defined in the targeted Rails application.
3. ^^ All basic Ruby classes are included, meaning this vulnerability is quite broad.
4. The YAML parser used by Ruby supports the serialization and deserialization of arbitrary data types. This includes Symbols and also arbitrary Objects.
5. SQLi (in the form of the arel object) is probably only the first of many different ways to exploit this, as it is essentially remote code execution.
6. Validate input. Seriously.
Mitigation
Upgrade Rails to one of the following releases: 3.2.11, 3.1.10, 3.0.19 or 2.3.15.
No comments:
Post a Comment