Rails 官方修正2.3 的digest authentication 的安全漏洞
喻选
A security problem has been reported with the digest authentication code in Ruby on Rails. This vulnerability can allow users to bypass your password protection. This vulnerability has been publicly disclosed on several websites, users are advised to take the mitigating steps described below immediately.
The issue comes from the handling of the block passed to authenticate_or_request_with_http_digest. This block must return the user’s password in the clear, or a sha1 hash of the user’s password. Unfortunately the documentation was unclear on this and the examples cited would return nil if the user was not found. The correct behaviour if the user doesn’t exist is to return false.
If the return value was nil, rails proceeded to verify this value against the provided password. Because of this an attacker can provide an invalid username and no password and authentication will succeed.
Fixed Versions
We have altered the behaviour of the relevant code to make nil an authentication failure. This fix has been pushed to 2-3-stable and will be present in 2.3.3 due to be released in the next few days. All versions of edge rails after commit 1ad57cfe2fbda58439e4b7f84008ad23bc68e8b0 contain the fix.
Steps to Protect your application.
Users can protect themselves without upgrading by simply ensuring that their authentication blocks never return nil. To take an example from the documentation:
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 ensure it doesn’t happen again in the future.
Nate Kontny of Inkling Markets has found a nasty security hole in the code example provided in both the documentation and blog post for the Digest Authentication functionality in Rails 2.3. If you've built your routine in a similar way to that as shown in the Rails documentation or blog post, you might be open to security issues.
Here's the code example in question:
Notice that authenticate uses the Users hash to authenticate the HTTP Digest Auth request? When you call hashes with non-existing keys, nil is returned. Luckily, Rails' digest authentication routines consider a response of nil as an authentication failure but if the password actually supplied is blank (ending up as nil), things don't quite work out as intended since nil == nil and you get right through the authentication!
Nate has written up a ton of info about this, including a test and a patch, and it's a must-read unless you're totally confident you have this covered already.
Worryingly, Nate claims that he has had little luck in raising this vulnerability with the Rails core team:
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.
The issue comes from the handling of the block passed to authenticate_or_request_with_http_digest. This block must return the user’s password in the clear, or a sha1 hash of the user’s password. Unfortunately the documentation was unclear on this and the examples cited would return nil if the user was not found. The correct behaviour if the user doesn’t exist is to return false.
If the return value was nil, rails proceeded to verify this value against the provided password. Because of this an attacker can provide an invalid username and no password and authentication will succeed.
Fixed Versions
We have altered the behaviour of the relevant code to make nil an authentication failure. This fix has been pushed to 2-3-stable and will be present in 2.3.3 due to be released in the next few days. All versions of edge rails after commit 1ad57cfe2fbda58439e4b7f84008ad23bc68e8b0 contain the fix.
Steps to Protect your application.
Users can protect themselves without upgrading by simply ensuring that their authentication blocks never return nil. To take an example from the documentation:
authenticate_or_request_with_http_digest(REALM) do |username|
USERS[username]
end
Should instead be something like:
authenticate_or_request_with_http_digest(REALM) do |username|
USERS[username] || false
endDisclosure 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 ensure it doesn’t happen again in the future.
Nate Kontny of Inkling Markets has found a nasty security hole in the code example provided in both the documentation and blog post for the Digest Authentication functionality in Rails 2.3. If you've built your routine in a similar way to that as shown in the Rails documentation or blog post, you might be open to security issues.
Here's the code example in question:
class PostsController < ApplicationController
Users = {"dhh" => "secret"}
before_filter :authenticate
def index
render :text => "You needed a password to see this…"
end
private
def authenticate
realm = "Application"
authenticate_or_request_with_http_digest(realm) do |name|
Users[name]
end
end
end
Notice that authenticate uses the Users hash to authenticate the HTTP Digest Auth request? When you call hashes with non-existing keys, nil is returned. Luckily, Rails' digest authentication routines consider a response of nil as an authentication failure but if the password actually supplied is blank (ending up as nil), things don't quite work out as intended since nil == nil and you get right through the authentication!
Nate has written up a ton of info about this, including a test and a patch, and it's a must-read unless you're totally confident you have this covered already.
Worryingly, Nate claims that he has had little luck in raising this vulnerability with the Rails core team:
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.
类似资料：