Lucene search

K
archlinuxArchLinuxASA-201611-15
HistoryNov 16, 2016 - 12:00 a.m.

[ASA-201611-15] python-django: multiple issues

2016-11-1600:00:00
security.archlinux.org
517

7.5 High

CVSS2

Attack Vector

NETWORK

Attack Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:N/C:P/I:P/A:P

9.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

0.017 Low

EPSS

Percentile

87.7%

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

OSVersionArchitecturePackageVersionFilename
ArchLinuxanyanypython-django< 1.10.3-1UNKNOWN

7.5 High

CVSS2

Attack Vector

NETWORK

Attack Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

PARTIAL

Availability Impact

PARTIAL

AV:N/AC:L/Au:N/C:P/I:P/A:P

9.8 High

CVSS3

Attack Vector

NETWORK

Attack Complexity

LOW

Privileges Required

NONE

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

0.017 Low

EPSS

Percentile

87.7%