

Security hole found in Rails 2.3's http_authentication.rb - nate
http://n8.tumblr.com/post/117477059/security-hole-found-in-rails-2-3s

======
tptacek
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.

~~~
wglb
Not being a ruby programmer, is there a defensive coding idiom that would have
prevented this confusion?

~~~
rcoder
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.

~~~
wglb
Thanks.

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

~~~
tlrobinson
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/...](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-
talk/324389)). 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.

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

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

~~~
nzkoz
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'

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

~~~
nzkoz
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.

~~~
prodigal_erik
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_.

------
csbartus
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...](http://groups.google.com/group/rubyonrails-
security/browse_thread/thread/20e17a978d2ccbd3?hl=en) 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.

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

~~~
nate
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)

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

