Vulnerability in JSON Parser in Ruby on Rails 3.0 and 2.3

It's safer to only use vulnerability counts as a metric for how interesting software is to security researchers.

A different version notation is needed to know whether the version delta between your installation and the most recent contains vital security updates.

https://groups.google.com/forum/?fromgroups#!forum/rubyonrai...

I probably wouldn't allow a production app to update itself without human intervention.

The problem is that it is simply untenable for all but the highest-profile sites. Finding good ops people, even in the bay area, is extremely hard. Most sites are only going to realize that a security update has been released when their package manager tells them it has, and updating that package is usually a 30s process.

The companies I've seen have a hard enough time keeping track of security updates with package management. For a small to medium team with two, one, or even zero dedicated ops people, asking them to custom-compile (for example) a webserver, ruby implementation, and other critical libraries (openssl, glibc, etc.), subscribe to the relevant security mailing lists, and follow along with updates and security patches is tantamount to having them leave unpatched vulnerabilities on their systems for months or even years.

If you ask your users to change passwords every 30 days, there are inevitably going to be a few who take it seriously and generate and remember secure passwords every single time. But the vast majority are going to use weaker passwords than they otherwise would have, and duplicate those passwords across accounts as much as they can figure out how. Likewise, if you ask already overworked ops guys to manually compile and keep track of security vulnerabilities for their webserver and dozens of libraries, a few are inevitably going to keep on top of things and release fixes minutes after vulnerabilities are announced. But the vast majority are going to simply give up after a month or two and be significantly worse off than if they just use Ubuntu's automatic security package updates.

Still doesn't fix the fundamental problem though. Let's say you automatically install updates on a staging server and automatically deploy to production if all tests pass.

What do you do when you're faced with a choice of deploying an app with a few failed tests (for perhaps not totally clear reasons) or leaving an old version up with a vulnerability?

http://www.hnsearch.com/search#request/submissions&q=dja...

Django has had its fair share of patches. This is no reflection on the quality of the project, as it shouldn't be for any sufficiently complicated framework (like Rails).

I also think the vulnerabilities are similar enough to suggest that the first one gave valid reason to ensure the same issue doesn't occur elsewhere. Rather than dusting these issues under the rug or silently fixing them, they're being responsibly reported with patches and updates provided at the same time.

This doesn't seem like broken process to me.

In my opinion, the fact that someone bothered to comb through 2.3.x and 3.0.x to find exploits similar to the last one points to a very good process, not a broken one.

Not all Django vulnerabilities have been discovered or reported yet. Just because no one has found or reported a vulnerability, doesn't mean that it it doesn't exist.

I'm actually going on a Rails security safari later, though not particularly looking to widen this/these vulnerabilities. I figure I've gotten enough out of the community over the years to contribute part of a workweek and get one more hole plugged.

One would think this is strictly less important than "root your server" but that hasn't been true for 100% of Rails developers that I've recently spoken to so, if losing your Macbook is the inducement you need to drop everything you are doing and patch, I will supply that inducement liberally.

> Symfony applications are not vulnerable to this attack

And it definitely has not the same track record. For example, it has been audited by a security company in one of the first versions. So far I have only seen minor security vulnerabilities, nothing like what Rails brings every week.

Anyway, that's not why I changed. I found it to be much better architected, 100% decoupled (as opposed to monolithic). You can change anything you want if you have to, or if you find better vendors and want to try them. It has actually been designed from day 1, and not by someone who has read about design patterns little time before creating the framework, and calls himself 'the master chef'.

Having an OOP background, I thought (I don't remember why) Ruby/RoR community was some sort of elite, and everyone had a much higher minimum level (as opposed to php, where most people are noobs). I was disappointed, most of them didn't even understand what interfaces were for (no wonder ruby hasn't added them yet), let alone knowing the most basic design patterns. They also seem to enjoy laughing at developers from other languages. All this was a pain to watch, but I didn't care as long as Rails was perfect, and that's how I felt about it at first. But it wasn't, so I moved to Symfony2, and found out not only the framework was superior, but also the community was awesome.

You are free to dislike Rails design, but you can't blame it for some vanilla parser bug.

Parsers are fertile ground for bugs, because they are by definition exposed to arbitrary input.