Django: Multiple vulnerabilities

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

===========================================================================
                         AUSCERT Security Bulletin

                               ASB-2016.0100
                     Django: Multiple vulnerabilities
                              3 November 2016

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:              Django
Operating System:     UNIX variants (UNIX, Linux, OSX)
                      Windows
Impact/Access:        Unauthorised Access  -- Remote/Unauthenticated      
                      Cross-site Scripting -- Remote with User Interaction
Resolution:           Patch/Upgrade
CVE Names:            CVE-2016-9013 CVE-2016-9014 
Member content until: Saturday, December  3 2016
Reference:            https://www.djangoproject.com/weblog/2016/nov/01/security-releases/

OVERVIEW

        Multiple vulnerabilities have been identified in Django prior to 
        releases 1.8.16, 1.9.11 and 1.10.3. [1]


IMPACT

        Django has provided the following details regarding the 
        vulnerabilities: 
        
        "CVE-2016-9013: User with hardcoded password created when running 
        tests on Oracle
        
        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).
        
        A randomly generated password is now used for each test run.
        
        Thanks Marti Raudsepp for reporting the issue."[1] 
        
        "CVE-2016-9014: DNS rebinding vulnerability when DEBUG=True
        
        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.
        
        Thanks Aymeric Augustin for reporting the issue."[1]


MITIGATION

        Django encourages all users to update to the latest release to fix 
        these issues.[1]


REFERENCES

        [1] Django security releases issued: 1.10.3, 1.9.11 and 1.8.16
            https://www.djangoproject.com/weblog/2016/nov/01/security-releases/

AusCERT has made every effort to ensure that the information contained
in this document is accurate.  However, the decision to use the information
described is the responsibility of each user or organisation. The decision to
follow or act on information or advice contained in this security bulletin is
the responsibility of each user or organisation, and should be considered in
accordance with your organisation's site policies and procedures. AusCERT
takes no responsibility for consequences which may arise from following or
acting on information or advice contained in this security bulletin.

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours 
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
===========================================================================
-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQIVAwUBWBrIZox+lLeg9Ub1AQhp/g//SnXS8Pf7GcmDo/U7NbZz9AIqhdGK/5sa
dhDj6tBK6WKpUVT+sHqJt4ziodGKNb3EHcp/LxK6R/NR5+qWFBIN8jpJ2NLFaZVL
Hj+Gw2W9l+eOAY1h2biMTXYKQUGs8/5tSJo9qqMM571fdb4H1GaSRm4fRdKw5VDZ
0nToop2YT83gvMjzdt6ha1AnnL7ew4wv6rda7IszyClG4Ni9cVjYi9CW4eMDlbKX
uVIcuyu5hVzqy3+yb291fb34/qiI+7Ywpz9l11ygHBSzQ43GlNob6eap8kwc8MLj
mBU0oIwTr/lCs3LI3Uo5ZFyhXPm5JoJU7bnnfflhdRrdvkX3O+1793oRRlCIN0KB
yZoXxuUhwqkraFKhomBkWJorDv4oR2sDaGeJFZs/kfZpzFEr6Ab4C/CCKP48BrSu
Ek76ZwQ/BlCevZiKem89igamyJRGeR59IA81csJXt//Uh8LzrWISw62Mt8cXQ6H1
B8O0T0vlts70sK+uKK2rISJjoXJeTR5IJpPHcOEbTYWaK+70i8hMA/XO0Z09Q/qM
TkEg0L3lKdsqyTUmMqWKzjj/3E5NbQ8SVMv+GgCzLZULoNAb0eWn9ohJbvaDH45b
mWsoR+hBsuwt9IOVFa6rHhqSxvPcpBGUVmvpDr9pi1NnMHjul4GCO6ssCHJDj9vk
QstHJIAQ/tk=
=YoYm
-----END PGP SIGNATURE-----