Skip to content

Comment on Exploitation of an old Rails vulnerability

Comments

Some people in that thread are running rails 3.2.9 end even 3.2.3, and the cited malicious requests contain url paramters the dedoce to ?id=\n---\n!ruby/object:Gem::Requirement\nrequirements:\n -

I.e., they have been grossly negligient in their server maintenance for most of this year. http://www.kalzumeus.com/2013/01/31/what-the-rails-security-...

[Edit: although at least one mentions 3.2.11, which should have that particular vulnerability fixed, so it will probably at least sometimes be someting else.]

On exactly this subject, I'm in the process of building a SaaS app that will alert you of security vulnerabilities in Gems in your Rails and other Ruby apps.

Sign up at my landing page to here more when I'm closer to launch

http://www.rubyaudit.com

You should know that New Relic is already doing this with Rails versions right now

Doesn't seem to be anywhere to sign up.

Doh! I just got the landing page setup, and the signup configured, but never pushed it out.

Try it now.

Thanks

Interesting idea, it looks like you scan the Gemfile.lock (or equivalent) at "deploy" time.

My preference would be to upload that Gemfile.lock to a location, and then it could be scanned as and when new vulnerabilities were detected.

The problem with an upload is that you rely on someone to re-upload when they change their Gems. Changing the locked Gems means a re-check is needed, as they might have switched to bad versions.

Making this automatic is the key part - if you don't get burned very often, you'll eventually forget to do the right thing manually and open yourselves to badness.

Yes. Looks like a case of explotation of CVE-2013-0156.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.