Hi everybody.
I’d like to announce that Devise v2.2.3, v2.1.3, v2.0.5 and v1.5.4 have been released with a security patch. Upgrade immediately unless you are using PostgreSQL or SQLite3. Users of all other databases (including NoSQL ones) require immediate upgrade.
Using a specially crafted request, an attacker could trick the database type conversion code to return incorrect records. For some token values this could allow an attacker to bypass the proper checks and gain control of other accounts.
In case you are using a Devise series older than the ones listed above, recommendations are provided below back to v1.2 series. Regardless, an upgrade to more recent versions is advised.
Versions affected
We checked all Devise versions released in the previous two years and recommendations follows as below.
v1.5, v2.0, v2.1 and v2.2 series
You can upgrade to any of v2.2.3, v2.1.3, v2.0.5 and v1.5.4. In case an upgrade is not feasible, please add the following patch to config/initializers/devise_patch.rb
inside your Rails application:
Devise::ParamFilter.class_eval do
def param_requires_string_conversion?(_value); true; end
end
v1.4 series
Please add the following patch to config/initializers/devise_patch.rb
inside your Rails application:
Devise::Models::Authenticatable::ClassMethods.class_eval do
def auth_param_requires_string_conversion?(value); true; end
end
Please upgrade to more recent versions.
v1.2 and v1.3 series
Not affected by this vulnerability. Please upgrade to more recent versions.
Upgrade notice
When upgrading to any of v2.2.3, v2.1.3, v2.0.5 and v1.5.4, some people may be relying on some wrong behaviour to filter data retrieved on authentication. For example, one may have writen in his model:
def find_for_authentication(conditions)
conditions[:active] = true
super
end
The code above may no longer work and needs to be rewriten as:
def find_for_authentication(conditions)
find_first_by_auth_conditions(conditions, active: true)
end
Thank you notes
We would like to thank joernchen of Phenoelit for disclosing this vulnerability and working with us on a patch.
Just RDBMSes affected or NoSQL databases, too?
We were not able to test all available databases. Besides, for NoSQL databases, the issue may also be caused by their respective ORMs, which makes it hard to guarantee they are not affected.
That said, *upgrade is required for everyone not using PostgreSQL or SQLite3 *.
Is there a way to filter this at the firewall level while I spend the time to upgrade correctly?
You can temporarily block all Devise routes related to extra functionality like unlocking, reset password and others. Just leave the sign in, sign out (database_authenticatable), sign up and account edit pages (registerable) and you must be good.
From the blog post, it’s a little unclear what the vulnerability allows the attacker to do.
From that sentence: “Using a specially crafted request, an attacker could trick the database type conversion code to return incorrect records. For some token values this could allow an attacker to bypass the proper checks.”
I understand that the attacker can read arbitrary data from the database. Is that correct? Or does the vulnerability let the attacker log in as someone else?
Thanks for the clarification!
Good point. It allows an attacker to bypass the proper checks and therefore log in as someone else.
I would also like to know if this affects NoSQL solutions, specifically Mongoid.
It looks like there’s a fix for ruby 1.8.7 on the 2.1 branch. Should we be expecting another release?
The fix changed just a test and documentation that used 1.9 syntax. We won’t release a new version, the current one is good to go.
> For some token values this could allow an attacker to bypass the proper checks and gain control of other accounts.
Does an attacker need to have an account on a site in order to be able to attack it? Eg, if I have a site with a couple of admin accounts but no user accounts, can an anonymous user gain control of the admin accounts?
Thanks
Yes, an anonymous user can gain control. Please update immediately.
Thanks for the quick reply.
This issue has been assigned CVE-2013-0233, as per http://www.openwall.com/lists/oss-security/2013/01/29/3.
We’re using PostgreSQL but not ActiveRecord, using Sequel instead. Do you know if it could be affected by such a bug?
Hello,
I use PostgreSQL, why I don’t need to upgrade on 1.5.4 ?
Was the 1.1 series evaluated? 1.1.9 came out in March 2013, which is less than 2 years ago.
You are not required to upgrade immediately but please do upgrade when possible.
I have tried the latest Sequel and DM version and they did not manifest the issue for PostgreSQL and SQLite3 as well. But upgrading eventually is always a good idea.
We did not evaluate it. Although 1.1.9 came out less than 2 years ago, the first release of the v1.1 series is more than 2 years and a half old.
The first release of the series is what matters. For example, just because we had released 1.5.4 yesterday, it does not mean we are going to maintain the whole series for more two years due to yesterday’s release.
Upgrade to Devise 1.2 (or more recent) immediately.
Obrigado pela resposta José. No momento eu prefiro não atualizar o Devise visto que eu tenho uma estratégia personalizada, bem como um encoder personalizado e quero evitar de ter problemas com eles agora, já que estou no meio de uma série de alterações no momento… De qualquer forma, minha aplicação não faz a autenticação usando Devise, mas usando o framework Shiro em uma aplicação Grails. O Devise é usado apenas em algumas urls que são redirecionadas pelo nginx e uma estratégia vai enviar os cookies para a aplicação Grails usando um endereço interno para obter o id do usuário atual. Essa autenticação é armazenada então nos cookies do Devise com session timeout de 10 minutos. Como não vi muitos detalhes de como essa falha de segurança afeta o Devise, não sei bem se ela se aplicaria ao meu caso… Mas certamente quando as coisas desacelerarem um pouco por aqui eu pretendo atualizar o Devise para a versão mais nova. O Sequel já está na versão mais nova…