Bugzilla – Bug 968000
VUL-0: CVE-2016-2513: python-django, python-Django: User enumeration through timing difference on password hasher work factor upgrade
Last modified: 2018-05-07 22:36:39 UTC
bugbot adjusting priority
Public at https://www.djangoproject.com/weblog/2016/mar/01/security-releases/ CVE-2016-2513: User enumeration through timing difference on password hasher work factor upgrade In each major version of Django since 1.6, the default number of iterations for the PBKDF2PasswordHasher and its subclasses has increased. This improves the security of the password as the speed of hardware increases, however, it also creates a timing difference between a login request for a user with a password encoded in an older number of iterations and login request for a nonexistent user (which runs the default hasher's default number of iterations since Django 1.6). This only affects users who haven't logged in since the iterations were increased. The first time a user logs in after an iterations increase, their password is updated with the new iterations and there is no longer a timing difference. The new BasePasswordHasher.harden_runtime() method allows hashers to bridge the runtime gap between the work factor (e.g. iterations) supplied in existing encoded passwords and the default work factor of the hasher. This method is implemented for PBKDF2PasswordHasher and BCryptPasswordHasher. The number of rounds for the latter hasher hasn't changed since Django 1.4, but some projects may subclass it and increase the work factor as needed. A warning will be emitted for any third-party password hashers that don't implement a harden_runtime() method. If you have different password hashes in your database (such as SHA1 hashes from users who haven't logged in since the default hasher switched to PBKDF2 in Django 1.4), the timing difference on a login request for these users may be even greater and this fix doesn't remedy that difference (or any difference when changing hashers). You may be able to upgrade those hashes to prevent a timing attack for that case. Thanks Sjoerd Job Postmus for reporting the issue. master: https://github.com/django/django/commit/67b46ba7016da2d259c1ecc7d666d11f5e1cfaab 1.9: https://github.com/django/django/commit/af7d09b0c5c6ab68e629fd9baf736f9dd203b18e 1.8: https://github.com/django/django/commit/f4e6e02f7713a6924d16540be279909ff4091eb6
This is an autogenerated message for OBS integration: This bug (968000) was mentioned in https://build.opensuse.org/request/show/589964 42.3 / python-Django
This is an autogenerated message for OBS integration: This bug (968000) was mentioned in https://build.opensuse.org/request/show/590768 42.3 / python3-Django
openSUSE-SU-2018:0824-1: An update that fixes 12 vulnerabilities is now available. Category: security (moderate) Bug References: 1001374,1008047,1008050,1031450,1031451,1056284,1083304,1083305,967999,968000 CVE References: CVE-2016-2048,CVE-2016-2512,CVE-2016-2513,CVE-2016-6186,CVE-2016-7401,CVE-2016-9013,CVE-2016-9014,CVE-2017-12794,CVE-2017-7233,CVE-2017-7234,CVE-2018-7536,CVE-2018-7537 Sources used: openSUSE Leap 42.3 (src): python3-Django-1.8.19-5.3.1
openSUSE-SU-2018:0826-1: An update that fixes 12 vulnerabilities is now available. Category: security (moderate) Bug References: 1001374,1008047,1008050,1031450,1031451,1056284,1083304,1083305,967999,968000 CVE References: CVE-2016-2048,CVE-2016-2512,CVE-2016-2513,CVE-2016-6186,CVE-2016-7401,CVE-2016-9013,CVE-2016-9014,CVE-2017-12794,CVE-2017-7233,CVE-2017-7234,CVE-2018-7536,CVE-2018-7537 Sources used: openSUSE Leap 42.3 (src): python-Django-1.8.19-6.4.1
This was fixed in Django 1.8.10: https://docs.djangoproject.com/en/1.8/releases/1.8.10/ It was also fixed in Devel:Cloud:6 by this update: https://build.suse.de/package/rdiff/Devel:Cloud:6/python-Django?linkrev=base&rev=15 which came from an OBS update which unfortunately omitted this and several other CVE references in the .changes file: https://build.opensuse.org/package/rdiff/Cloud:OpenStack:Newton/python-Django?linkrev=base&rev=3 so the only remaining thing to do for the Cloud product is submit the newer version to SUSE:SLE-12-SP1:Update:Products:Cloud6:Update which is still on 1.8.9: $ iosc se --package -V python-Django | grep Cloud | egrep -v 'home:|Devel:Cloud:[1-5]|Cloud[1-5]|PTF' Devel:Cloud:6 python-Django 1.8.19 16 13b226703f97a22e6b1e843a7dddd332 Devel:Cloud:6:Milestone python-Django 1.6.11 9 f4865b97e5a3facf5eef7e96a5bcb4b2 Devel:Cloud:7 python-Django 1.8.19 1 de01e034d139cfcec9316aafd2f7121b Devel:Cloud:7:Mitaka python-Django 1.8.9 1 73af3fcb5673590bb0a80c15c5e00c47 Devel:Cloud:8 python-Django 1.11.11 1 d95fc81db22ecd01f2e9bb129b1da030 Devel:Cloud:8:Ocata python-Django 1.8.14 1 45ddf16fe3b7c0e96e2e73d3c048b612 Devel:Cloud:8:Pike python-Django 1.11.4 2 01745644cef38941882283de6309b295 Devel:PubCloud python-Django - 3 dbd76c1dece73aea895693898bd2b4c6 SUSE:SLE-12-SP1:Update:Products:Cloud6 python-Django 1.8.9 3 73af3fcb5673590bb0a80c15c5e00c47 SUSE:SLE-12-SP1:Update:Products:Cloud6:Update python-Django - 1 328eca9bf60a1fd8f43efaf2bcb8d1bb SUSE:SLE-12-SP2:Update:Products:Cloud7 python-Django 1.8.14 3 45ddf16fe3b7c0e96e2e73d3c048b612 SUSE:SLE-12-SP2:Update:Products:Cloud7:Update python-Django - 1 b35e9764c911eccfdbdb18ef069578cd SUSE:SLE-12-SP3:Update:Products:Cloud8 python-Django 1.11.11 3 30b4b4c919bcd997dd6611f5c3769577 I'll do that now.
(In reply to Adam Spiers from comment #11) > so the only remaining thing to do for the Cloud product is submit the newer > version to SUSE:SLE-12-SP1:Update:Products:Cloud6:Update which is still on > 1.8.9: > > $ iosc se --package -V python-Django | grep Cloud | egrep -v > 'home:|Devel:Cloud:[1-5]|Cloud[1-5]|PTF' [...] > SUSE:SLE-12-SP1:Update:Products:Cloud6 python-Django > 1.8.9 3 73af3fcb5673590bb0a80c15c5e00c47 > SUSE:SLE-12-SP1:Update:Products:Cloud6:Update python-Django - > 1 328eca9bf60a1fd8f43efaf2bcb8d1bb Ah no, I misread this. SUSE:SLE-12-SP1:Update:Products:Cloud6 is on 1.8.9 but SUSE:SLE-12-SP1:Update:Products:Cloud6:Update was updated to 1.8.19 7 days ago: https://build.suse.de/request/show/160565 Unfortunately for the same reason as before, the .changes delta didn't mention the CVE number, and also it didn't mention this bug. So there is nothing left to do from the Cloud side here. Looks like the SES folks still have some work to do though: https://build.suse.de/package/show/SUSE:SLE-12-SP2:Update:Products:SES4:Update/python-Django https://build.suse.de/package/show/SUSE:SLE-12-SP3:Update:Products:SES5:Update/python-Django
Not sure who on the SES team should be assigned this, so resetting ownership to default.
Just been informed I can use ceph-bugs@suse.de so here you go :)