This means all RoR users should upgrade immediately to a patched version of the software to avoid the risk of full remote code execution against any RoR application.
The vulnerabilities (CVE-2013-0155 and CVE-2013-0156) deal with how data entered by the user is parsed and handled by the RoR application.
CVE-2013-0156 allows full remote code execution against any RoR application that has the XML parser enabled, said Adam O’Donnell, chief architect in the Cloud Technology Group at security firm Sourcefire.
“It means that anyone can run a Unix command with the same privileges as the Ruby on Rails application under the default install,” he wrote in a blog post.
Both issues can be remediated by RoR programmers and administrators by upgrading to the latest version of RoR, and there are workarounds if this is not an option, said O’Donnell.
CVE-2013-0155 can be addressed only by adding additional data parameter scrubbing code to the application, while the CVE-2013-0156 can be addressed by disabling the XML parser.
“This may not be an option for every website as they may consume XML from the user as a matter of routine operation,” said O’Donnell.
Read more about RoR
- Ruby on Rails Tutorial
- Hot skills: Ruby on Rails
- Salesforce.com acquires Ruby on Rails firm Heroku for £134m
- Learn about Ruby on Rails programming
- Hot Skills: Ruby and Ruby on Rails
- Ruby on Rails security audit service available
- Where Ruby on Rails fits into SOA
- Hot skills: Ruby on Rails 2.0
- Ruby, PHP, .NET platforms show various advantages for PaaS development
- Web services with Ruby on Rails
He urged all those using the framework to take the matter seriously because the vulnerabilities appear to allow anyone to execute commands on the web server that hosts the software, as well as pull any data out of the back-end database that the web server itself can access.
O’Donnell warned that many organisations could be vulnerable for hours or days, some for weeks or longer because changing a programming framework is no small task.
Many organisations need to go through several steps between development and testing and finally deployment.
“During this window the only thing that will stop an attacker is some form of network-layer technology that understands how the vulnerability is exploited,” he said.
According to O’Donnell, the RoR vulnerability could be used for the creation of a worm, but it would be far worse if attackers were to use the vulnerability to silently compromise massive numbers of vulnerable websites, grab everything from the database, and install persistent back doors in the infrastructure of every organisation running the vulnerable code.
“They could also silently post a client-side exploit that targets people who come to that site, commonly known as a Watering Hole attack. A worm would likely force everyone to fix their infrastructure immediately, while silent exploitation may not be as motivating,” he said.
O’Donnell advises anyone running Ruby on Rails code to upgrade the RoR environment immediately.