Security announcement: Devise v2.2.3, v2.1.3, v2.0.5 and v1.5.4 released

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.

20 responses to “Security announcement: Devise v2.2.3, v2.1.3, v2.0.5 and v1.5.4 released”

  1. HankShatner says:

    Just RDBMSes affected or NoSQL databases, too?

  2. josevalim says:

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

  3. Chris Schneider says:

    Is there a way to filter this at the firewall level while I spend the time to upgrade correctly?

  4. josevalim says:

    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.

  5. 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!

  6. josevalim says:

    Good point. It allows an attacker to bypass the proper checks and therefore log in as someone else.

  7. wedtm says:

    I would also like to know if this affects NoSQL solutions, specifically Mongoid.

  8. It looks like there’s a fix for ruby 1.8.7 on the 2.1 branch. Should we be expecting another release?

  9. josevalim says:

    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.

  10. Marc Kelsey says:

    > 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

  11. josevalim says:

    Yes, an anonymous user can gain control. Please update immediately.

  12. Marc Kelsey says:

    Thanks for the quick reply.

  13. reed says:

    This issue has been assigned CVE-2013-0233, as per http://www.openwall.com/lists/oss-security/2013/01/29/3.

  14. We’re using PostgreSQL but not ActiveRecord, using Sequel instead. Do you know if it could be affected by such a bug?

  15. Hello, 
    I use PostgreSQL, why I don’t need to upgrade on 1.5.4 ? 

  16. nicholaides says:

    Was the 1.1 series evaluated? 1.1.9 came out in March 2013, which is less than 2 years ago.

  17. josevalim says:

    You are not required to upgrade immediately but please do upgrade when possible.

  18. josevalim says:

    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.

  19. josevalim says:

    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.

  20. 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…