CVE-2011-4136

What it actually does

The vulnerability causes a namespace collision in Django's cache-based session backend. Session identifiers and application data keys are stored in the same root namespace. An attacker who can control a cache key can force it to be the same as a victim's session ID, causing the application to overwrite the victim's session data with attacker-controlled data. This leads to session data integrity loss and potential session-specific denial of service.

Why it matters to the business

Attackers can corrupt or tamper with user sessions, leading to unpredictable application behavior for affected users. This could result in users being unexpectedly logged out, having their application state (like a shopping cart) modified without their consent, or being denied service. Such disruptions erode user trust and can negatively impact application usability and reliability.

How an attack unfolds

A remote, unauthenticated attacker first identifies a target user's session ID. The attacker then interacts with a part of the Django application that caches data based on user-controllable input. By crafting a specific request, the attacker forces the application to create a cache entry where the key is identical to the victim's session ID. The cache backend, lacking namespace separation, overwrites the legitimate session data with the attacker's new cache entry. When the victim's browser next makes a request, the application reads the corrupted session data, leading to session fixation, data tampering, or a session-level denial of service.

How to fix it

Upgrade Django to a patched version. For applications running Django 1.2.x, upgrade to version 1.2.7 or later. For applications running Django 1.3.x, upgrade to version 1.3.1 or later. If an immediate upgrade is not possible, consider changing the session engine from 'django.contrib.sessions.backends.cache' to a different backend (e.g., 'django.contrib.sessions.backends.db') as a temporary mitigation, but be aware of potential performance impacts.

How to confirm the fix worked

To confirm remediation, check the installed Django version in your application's environment using the command `python -m django --version`. Ensure the version is 1.2.7 or higher, or 1.3.1 or higher. To test for the vulnerability in a pre-production environment, one could attempt to manually trigger a cache write with a key that matches a known session ID and verify if the session data is overwritten.

Typical attack path

1. An attacker identifies a Django application using a vulnerable version with a cache-based session backend.
2. The attacker obtains or predicts a target user's session ID.
3. The attacker finds an application feature that caches data where the cache key can be influenced by user input.
4. The attacker sends a crafted request to trigger a cache write operation with a key that matches the victim's session ID.
5. The cache backend overwrites the victim's session data with the attacker-controlled data.
6. The victim's session becomes corrupted, leading to data manipulation or denial of service for that user.

How to detect it

Detection of exploitation is challenging as it involves abusing legitimate cache functionality. Monitor application logs for a high rate of session-related errors, such as deserialization failures or unexpected session data types, which could indicate session corruption. If extensive logging is available, look for cache write operations where the cache key has the format of a session ID but the value is not a valid serialized session object. This type of detection requires deep application-specific instrumentation.

What your security team should do

• Immediately upgrade all applications using vulnerable Django versions to a patched release (1.2.7+ or 1.3.1+).
• Use dependency scanning tools to identify all projects using affected Django versions.
• If patching is delayed, assess the risk and consider switching the session backend away from the cache as a temporary workaround.