Security problem with authenticate_with_http_digest

85 views
Skip to first unread message

Michael Koziarski

unread,
Jun 3, 2009, 7:09:30 PM6/3/09
to rubyonrail...@googlegroups.com
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:

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
end

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.

--
Cheers

Koz

Reply all
Reply to author
Forward
0 new messages