Item — HN Reader

"Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use lighthouse for reporting security vulnerabilities. All content in lighthouse is publicly available as soon as it is posted."

Yes, as I mention in the blog post, I've attempted to contact this security list and a couple members on the core team through their individual email accounts over a week ago. I've only received one response last Thursday that someone would look into it, but the issue seemed to die there.

Now that enough time has been given for the security list to look into the problem (and hopefully not ignore it), the best practice I thought would be to tell as many people as possible about it so the fix can be applied and publicized. I felt I'd get a lot bigger audience here at Hacker news than the rails bug tracker. The bigger the audience the more people that can get their Rails 2.3 instances fixed if they are effected and avoid a problem. I was also planning on posting it there, but feel free to do it as well.

3 comments

This is an absolutely classic indie/startup security fuckup. (1) Have a security contact, (2) publish a GPG key and accept GPG mail, (3) respond promptly with a "security flaw ID".

You literally don't have to do anything more than this --- mechanically --- to get good-faith people not to publish flaws publicly.

Where should the security contact information be?

If you found a flaw on site example.com, where would you look first for a security contact?

/security, security@, the "security" tab on the front page.

Depends on the protocol the security flaw is with, but RFC 2142 would indicate that if it's a Web issue, then webmaster@example.com - sadly people don't pay attention to many standards like this anymore, though, because they'd rather the Internet be broken.

A weird comment, since this isn't a web issue, it's an issue with a software library.

Probably "feedback", "contact us", and "support", roughly in that order.

Nate,

I'm sorry that you weren't told that we were working on this as part of a point release that was due out in the next 24 hours. Clearly there's been a failure in communications somewhere along the line. For what its worth your emails to the security list never arrived in my inbox. There's something wrong with one of our mail servers, but other messages to that list arrive frequently.

However I remain incredibly disappointed that you posted this so publically without so much as following up one more time with pratik, or emailing the rails core list or anything.

The wheels were in motion with this one, and drama like this will merely distract people from the issues at hand.

Michael Koziarski Rails Core Team Member and 'Dude who gets the security emails'

I had attempted to keep the drama and subjective language out of my post and communication about this.

I think the developers working on Rails including you, Koz :) does a killer job at making the best development framework we got. I am very grateful for your work.

But I feel you and the other members that were notified of this were the ones who acted irresponsibly - to use your words in your other communication I now have from you.

I began this over a week ago (May 26 to be exact) with a report, tests, and a fix for the problem to the security list, which is the official channel that has been provided to us.

I felt that this was a large enough deal that I wrote another core member (Core Member A) (I'm leaving names out of this) the next day (May 27) because I had heard nothing. I alerted him that I had not heard from the security list. I received no response again in 24 hours.

So I emailed a third time the security list as well as the core member from May 27 as well as another core member (Core Member B) on May 28 with

"Hey guys, just trying one more time before I make this a more public issue. This seems like a MAJOR deal. "

I also included a working example just to make it easier to see in 2 seconds something was wrong.

I finally got a response from Core Member A on May 28 that this would be looked into over the weekend.

I felt it was a poor decision to take days before someone even "looks into it", days after you've been notified about a security problem. But I kept my lips sealed and hoped for the best, and now it's over a week later and felt it was now irresponsible on my part for letting this go this long.

No one seemed to actually be taking this seriously, and this appeared to be a serious problem. And already a public one.

Here's a guy complaining about what might appear to be the same thing:

http://osdir.com/ml/RubyonRailsTalk/2009-04/msg01035.html

Back in April.

People needed a fix and the knowledge that something was wrong ASAP.

I apologize for not being a security flaw reporting expert, but I have seen other responsible security flaw reporters have given anywhere from 24 hours to a week of time to a vendor or open source core to fix a vulnerability before publicly releasing.

I gave you guys that, and even told you my 3rd email would be my last attempt at getting your help with this. And like I said, this looks like it was already knowledge in the public domain, I just provided a fix and made people aware they might be getting their ass kicked while I try and try and try without effect at getting a new point release or announcement mention from anyone in Rails core.

There is also a tangential issue. One of the core members (Core Member B) I've emailed about this, I've also emailed privately a couple times about a security flaw in their applications (I've received 2 responses about looking into it, but no action has been taken to fix the problem). The behavior in that case made me feel that there was a trend in the Core team that enough attention is not being paid to security problems.

This behavior from the core team led me to think that the responsible thing was to take this to the next level. And since the next level is to tell some more people, you better tell as many people as possible so that we can all protect ourselves.

As I've mentioned publicly and privately to you so far. All that it would have taken to prevent this difficulty would be a single reply to the email you received saying "just checking that you're working on this". That would have highlighted the fact that pratik forgot to tell you what was going on.

Instead we find ourselves here. I'm sorry that you feel so let down by the process, and I realise that you feel you've followed the right process. But fundamentally you've assumed malice where there was in fact a simple error. Had you taken a few minutes to check before doing this, we'd all have been better off.

Having said all that, we obviously need a more clearly documented "what to do when you don't get a reply" policy. We also need to move the email.

But fundamentally you've assumed malice where there was in fact a simple error.

No, he assumed incompetence, which you seem to be intent on proving by continuing to attack him and give this non-apology apology.

Had you taken a few minutes to check before doing this, we'd all have been better off.

Or you could've resolved this a week ago had you had a more mature process. The guy laid out the issue, presented a fix, and e-mailed you and the rest of the Core Team several times. How many more "few minutes" does he need to take before it stops being his fault in your opinion?

Stop attacking the guy, it's really poor form. Just admit you guys screwed up and move on.

Stop attacking the guy, it's really poor form. Just admit you guys screwed up and move on.

Sounds like Zed's analysis of the Rails community is still correct.

As someone who loves Rails, I'd hate to think that.

Yup - I'm amazed. The Rails community has gotten some flack for this kind of issue before, but rather than listen to the criticism and learn from it, they make the same mistake over and over.

It's as if they feel that Rails is a direct product of their personalities, and that because Rails is so successful, anything they do is vindicated by that success. That's just the wrong approach.

And this is why I loved merb and I'm still not sure the merge was a good thing....

The onus is on you to be responsive. If that's not going to work, then, respectfully, think about getting someone else to answer that email address? We ship Rails code; if it helps, we'll answer the mails.

The problem isn't just that the mails didn't go through; it's also that you apparently didn't tell the reporter where you were in the process. Before you express incredible disappointment, can you tell us that you asked him not to post?

Another piece of advice, from crisis management: don't feed the story. I'm actually interested in what your response was now (so I can learn more about how Rails handles stuff like this), but I don't see how your team benefits from hashing this disagreement out in public. It seems so lose-lose for you. Just apologize for the confusion and say you're fixing it and let the story go away.

We'll do a full announcement, and in a week or so report on what changes we've made (moving the mail server being an obvious one).

Nate was told that we were traveling and that we'd get back to him. I then went about fixing the issue, verifying there weren't similar issues in other areas of the framework etc.

Ideally we would have told nate the release timetable, but that wasn't clear yet. Clearly we messed up here. However I'd hope in future people would send an email saying "any update" before posting to their blog and crying 'unresponsive'.

You can't be incredibly disappointed in someone for not doing something you didn't ask them to do. You can probably let the issue drop there. I'm glad you're taking the flaw seriously.

I think that reporting the bug and then waiting approximately 2 weeks with no follow up from them warrants a public post so developers are forced to fix it.

Though I'm a cruel bastard, and I think most people would have sent off an email inquiring about the progress. But in this case it seems it would have made no difference as the mail server was down...

"I've only received one response last Thursday that someone would look into it, but the issue seemed to die there."

I am not clear here where the 24 hours starts.

I'm guessing 24 hours from now.

We'll push this fix to 2-3-stable and master now as the 'damage is done' in terms of disclosure.

The timeframe for the 2.3.3 point release is hopefully 'this week'. We're just waiting on a few other things to fall into place.

If you're trying to convince your community that it's better to work through your process, letting nebulous "other things" continue holding up a week-old one-line fix to a catastrophic security flaw is not helping. Disclosure enables everyone else to work around the problem now.

Here's a ticket now though. https://rails.lighthouseapp.com/projects/8994/tickets/2755-s...

And I've also put it up on rubyflow.