The vulnerability (CVE-2013-0333) affects older versions of the framework, versions 2.3.x and 3.0.x, according to an alert sent by software developer Michael Koziarski yesterday to the Ruby on Rails security group on Google Groups.
The vulnerability stems from a problem with the JSON parsing code that allows multiple parsing backends. For example, Ruby on Rails could parse YAML code, a markup format considered a superset of JSON. Since both forms of code are from the same family and both can be parsed by Ruby on Rails, it’s possible an attacker could take a payload and “trick the backend into decoding a subset of YAML.”
The warning on Google Groups directs Ruby on Rails users to fix the flaw with two patches, “2-3-json-parser.patch” and “3-0-json-parser.patch.” If users are unable to apply the patches, they’re encouraged to create a workaround by switching their backend to the JSONGem backend. Further instructions on the workaround, including the necessary code, can be found on the Google Groups alert.
Ruby on Rails has had a bit of a tough go of it on the security front to start off 2013. A SQL injection vulnerability affected all builds of the framework earlier this month that could’ve let an attacker inject code into web apps. While that was quickly patched, another problem with the framework emerged a few days later. Bugs surfaced that could have affected the way Ruby on Rails parses some parameters.
Similar to yesterday’s alert, a problem with the parser could have let attackers bypass authentication systems and inject arbitrary SQL, arbitrary code and open up the system to denial of service attacks. At the time, HD Moore, the creator of Metasploit warned the bug “is more than likely the worst security issue that the Rails platform has seen to date.” Exploit code and a Metasploit module that worked against versions 2.x and 3.x were developed and released soon after.
Yesterday’s Ruby on Rails post makes a point to note that this week’s vulnerability, while similar to the last parsing vulnerability (CVE-2013-0156), is a separate problem and that users “must still take action to protect [their] application.”