Researchers have warned of a remote execution exploit for dangerous Ruby on Rails flaws that were the subject of two "extremely critical" fixes this week.
The parameter-parsing flaws are present in all versions of Ruby on Rails and allow attackers to bypass authentication and execute arbitrary code in Rails apps.
Ruby on Rails maintainers warned of "multiple weaknesses in the parameter parsing code for Ruby on Rails which allows attackers to bypass authentication systems, inject arbitrary SQL, inject and execute arbitrary code, or perform a DoS attack on a Rails application".
Security researcher Ben Murphy said a proof of concept attack had been developed for all versions of Rails for the last six years, but had not yet been made public.
"An attacker can execute any ruby code he wants including system (unix command)," Murphy he wrote in a forum comment. "This affects any rails version for the last six years.
"I've written POCs for Rails 3.x and Rails 2.x on Ruby 1.9.3, Ruby 1.9.2 and Ruby 1.8.7 and there is no reason to believe this wouldn't work on any Ruby/Rails combination since when the bug has been introduced.
"The exploit does not depend on code the user has written and will work with a new rails application without any controllers."
Metaspolit developer HD Moore detailed the mechanics of the flaw in a blog post, including a local proof-of-concept exploit for Distributed Ruby (DRb) installations, and says a module will likely be developed within days.
"Stay tuned for more information on this flaw and more than likely a Metasploit module or two in the coming days," Moore wrote.
Developer Felix Wilhelm has offered more details into the vulnerability but did not list a working proof of concept exploit.
Sourcefire chief architect and PhD Adam J O'Donnell said a worm could emerge to target the vulnerabilities but such a threat would be overshadowed by more stealthy attacks.
"The worst case situation is that attackers use the vulnerability to silently compromise massive numbers of vulnerable websites, grab everything from the database, and install persistent backdoors in the infrastructure of every organisation running the vulnerable code," O'Donnell wrote.
"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."