back
39 comments
Yep, looks real enough to me. Confusion between "nil" and "false" in Ruby, where an assumed true/false return value actually takes on a third value that also matches a nil password.
Not being a ruby programmer, is there a defensive coding idiom that would have prevented this confusion?
You can always test for nil explicitly. Compare:

  unless foo
    # ... foo can be false or nil to reach this branch
  end

  unless foo == false
    # ... this branch is reached unless foo == false
  end
Since terseness is considered such a cardinal virtue amongst Ruby programmers (including myself), however, this kind of issue is often ignored, and difficult to detect unless your tests explicitly check for "truthy" and "non-truthy" values in addition to the true/false literals.
Thanks.
tell me in detail

  if object.nil?
    puts "Object is nil!"
  else
    puts "Object is not nil."
  end
Haskell obviously isn't Ruby, but its Maybe monad, where you have Just the login, or Nothing, looks pretty appealing.
Two thoughts:

1. It shows that tests are only as good as the thinking that goes into them, i.e., it's up the programmer to think through all the use cases, possibility for breakage, and use the appropriate tools to try a wide range of inputs.

2. This lack of responsiveness to the vulnerability reminds me of the complaints Zed (Shaw) made about the Rails Core back when he announced he was leaving the Ruby community.

Preemptive disclaimer: These are not supposed to be snide remarks in any way, they're just two quick associations of a tired brain. So please no flames.

Indeed, back in January I came across a directory traversal vulnerability in Rack (http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/...). They had lots of unit tests, but none testing that particular case. Unit testing is certainly no magic bullet.

On the other hand, the Rack team was incredibly responsive and put out an update within hours.

It's also an interesting example of where an Option/Maybe monad would save you. Coupled with a type system, the issue would even be caught at compile time (or edit-time, in the case of a type-aware editor/IDE).
I'm curious, did you submit a bug report for this patch? I can't find it on http://rails.lighthouseapp.com.

It seems odd to me that you would use Tumblr and Hacker News as a sounding board for a security flaw rather than submitting a bug report or notifying the Rails team through existing mailing lists.

"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.

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.

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.

a sad story, comparing to the recent arc/hn security hacking: http://news.ycombinator.com/item?id=639976

reading that post was delighting me: a serious bug, a fix added, a community supporting & being thankful.

here at rails, a framework i would like to love it, a serious bug, no fix, a community throwing the shit over the fence and each other.

this immediately reminds me of the recent pr0n story in rails, where some members of the community were offended, by whatever reasons, by other community members.

the only good, non-technical advancement in rails in the last period i saw was the documentation project supported by the community and backed by rails eminents.

i'm expecting a firm and strong support here from rails, either would it come from dhh, or anybody else.

otherwise even if i would like to work with rails and build my life on it i can't afford a serious security hole being treated like this.

ruby and almost in the same way rails are close to my heart. i'm always defending them in such cases, even making myself being too subjective.

i can accept rails edginess, mac-alike metrosexualism (no ofense to anyone!), handsomeness and awesomeness, funky geekness BUT in some cases, like this, we should act normally, promptly, professionaly as any other community does.

EDIT: the official rails core answer: http://groups.google.com/group/rubyonrails-security/browse_t... posted 10hrs ago this comment was made. it contains a bugfix, instructions and a disclosure i'm copying here:

Disclosure Notes ====

Due to communication difficulties and a mis-understanding between the reporter and the security team. This vulnerability has been publicly disclosed on several websites, users are advised to update their applications immediately. Steps are being taken to ensure that the security email is more reliable in the future. We regret the nature of this disclosure and will endeavor to update processes and documentation to ensure it doesn’t happen again in the future.

Interesting, I'm not getting this flaw at all. Which version of 2.3 is this addressing? Rails 2.3.1 only? I just tried this on a 2.3.2 app and got HTTP Basic: Access denied.
Rails 2.3.x. The app you tested this on, what's the password procedure like? One part of problem is doing a password procedure like "Users[name]" where Users is a hash of usernames/passwords. Also I believe this just effects folks doing digest auth (authenticate_or_request_with_http_digest) not basic auth (authenticate_or_request_with_http_basic)
IMO, you should write your own code, instead of relying on someone else's possibly buggy code. If you are going to use somebody else's code, you should at LEAST look at it to make sure its correct, especially something as terse as this.