Arch Linux Security Advisory ASA-201611-15 ========================================== Severity: High Date : 2016-11-16 CVE-ID : CVE-2016-9013 CVE-2016-9014 Package : python-django Type : multiple issues Remote : Yes Link : https://wiki.archlinux.org/index.php/CVE Summary ======= The package python-django before version 1.10.3-1 is vulnerable to multiple issues including access restriction bypass and authentication bypass. Resolution ========== Upgrade to 1.10.3-1. # pacman -Syu "python-django>=1.10.3-1" The problems have been fixed upstream in version 1.10.3. Workaround ========== - CVE-2016-9013 Ensure the debug mode is deactivated via: settings.DEBUG=False Description =========== - CVE-2016-9013 (authentication bypass) When running tests with an Oracle database, Django creates a temporary database user. In older versions, if a password isn't manually specified in the database settings TEST dictionary, a hardcoded password is used. This could allow an attacker with network access to the database server to connect. This user is usually dropped after the test suite completes, but not when using the manage.py test --keepdb option or if the user has an active session (such as an attacker's connection). - CVE-2016-9014 (access restriction bypass) Older versions of Django don't validate the Host header against settings.ALLOWED_HOSTS when settings.DEBUG=True. This makes them vulnerable to a DNS rebinding attack. While Django doesn't ship a module that allows remote code execution, this is at least a cross-site scripting vector, which could be quite serious if developers load a copy of the production database in development or connect to some production services for which there's no development instance, for example. If a project uses a package like the django-debug-toolbar, then the attacker could execute arbitrary SQL, which could be especially bad if the developers connect to the database with a superuser account. settings.ALLOWED_HOSTS is now validated regardless of DEBUG. For convenience, if ALLOWED_HOSTS is empty and DEBUG=True, the following variations of localhost are allowed ['localhost', '127.0.0.1', '::1']. If your local settings file has your production ALLOWED_HOSTS value, you must now omit it to get those fallback values. Impact ====== A remote attacker is able to bypass certain access restrictions that, depending on used django modules, is possibly leading to cross-site scripting or arbitrary SQL execution. Furthermore a remote attacker with network access to the database server is able to bypass the authentication. References ========== https://www.djangoproject.com/weblog/2016/nov/01/security-releases/ https://access.redhat.com/security/cve/CVE-2016-9013 https://access.redhat.com/security/cve/CVE-2016-9014