One of the questions that resulted from that, somewhat in shock, was how long this bug had existed in a public open-source project. Referring back to the original discoverer, it seems this bug has persisted through the lifetime of the Rails project (i.e. Rails 1.2 and 2.0 were vulnerable as well).

Looking back in time, we can actually see the March 2005 commit where the limit functionality was added to the MySQL adapter. If you have javascript enabled, I’ve pulled out the relevant bits below. The interesting thing to notice is that some sanitization is performed if both a limit and offset parameter exist, but if only the limit parameter exists…no sanitization is done.

There is some good discussion about how to exploit this :limit bug on the Ruby on Rails Security Project blog.

Finally, we can see where this SQL Injection was fixed earlier this year. And if you’re curious, here’s what sanitize_limit does.

That being said, I suppose we could enter into the old argument of whether closed or open-source is a more secure model. But realistically, bugs exist in any project – it’s the process and integration of security into that specific project’s development that determine it’s resulting security and risk profile.