Subversive Code

Firewalls are everywhere. They filter unexpected traffic, and log everything for later analysis. They improve security by restricting access to potentially vulnerable software that only needs to be accessed internally. They proactively filter ports and services which may have undiscovered vulnerabilities. They prevent information gathering which might aid a future attack. They’re relatively easy to deploy and don’t require as much specialized knowledge as other security methods. Firewalls work.

Firewalls are a crutch. They allow systems and network administrators to say that a network is secure without spending the time to secure each machine and component. They mean that the sysadmin may choose not to disable every unused service and port on a machine. They mean that companies use unprotected file shares rather than authenticating each user and encrypting the protocol. They allow administrators to deploy applications which are not secure, with the explanation that the firewall will make them so.

This has historically worked pretty well. Firewalls do work, after all.

Today the situation is different.

While firewalls are very good at blocking all kinds of inbound traffic, they necessarily allow outbound web traffic to pass through. Internet access is a requirement for most jobs, and so administrators install antivirus, keep desktop software up to date, and hope that they don’t get a motivated attacker with a new 0-day.

This also works pretty well, except for one thing:

A properly functioning, fully patched web browser is an ideal gateway to internal web-based assets that are “Behind the Firewall”. By design, the browser is able to access content from multiple domains, and the rise of javascript (and now the various features of HTML5) allow a remote attacker to pass requests through the firewall to be made internally by trusted machines. Frameworks like BeEF make this tunneling trivial. Add a little DNS trickery and a browser can be convinced to do pretty advanced scans of private networks.

Web applications deployed behind the firewall should be secure enough to deploy facing the internet. This is especially true when the code is written for internal consumption by programmers with a deadline. The firewall can prevent many evils, but it won’t prevent web browsers from behaving as designed.

Original announcement:

https://www.djangoproject.com/weblog/2011/feb/08/security/

When Django is used with the included file-based session storage
backend on Windows, it is vulnerable to a potential directory
traversal attack.

In django.contrib.sessions.backends.file._key_to_file():

36     # Make sure we're not vulnerable to directory traversal. Session keys
37     # should always be md5s, so they should never contain directory
38     # components.
39     if os.path.sep in session_key:
40         raise SuspiciousOperation(
41             "Invalid characters (directory components) in session key")
42
43      return os.path.join(self.storage_path, self.file_prefix + session_key)

Django takes a user supplied session key, checks to make sure it does
not contain os.path.sep, and then uses os.path.join() to create a
filename string which is later opened and unpickled to restore session
data.

The vulnerability lies in the check against os.path.sep. On Unix-like
systems, this returns the / character, which is the only standard way
to specify a directory separator. On Windows, this returns the \
character (the usual DOS path separator). The problem is that Windows
(and so Python) has always accepted either character as a path
separator [1].

This means that a string which only uses forward slashes does not trip
the Suspicious Operation check on Windows. Django happily accepts a
cookie with ‘sessionid=../../../maliciousfile’. It looks for the file,
and will follow the usual session restore procedures if it finds a
file at the user-supplied path.

Fortunately, Django hashes and verifies the contents of sessions
loaded in this manner. This means that without breaking the checksum
mechanism, the best an attacker is likely to be able to accomplish is
some kind of session replay attack where they are able to re-insert a
formerly valid session at will. This might be useful against systems
which store permissions or “value” of some kind in the session. If the
attacker is able to break the checksum mechanism [2], this attack
could lead to arbitrary code execution when pickle loads the stored
session.

The patch arrived in changeset 15476.

[1] You can’t usually type the / into a DOS command line as a
separator because it is set as the switch character. You can run the
DOS shell with a different switch character if you like.

[2] There are a bunch of known attacks on MD5. To the best of my
knowledge, the particular ways that Django uses it in this case are
not currently vulnerable to the easy attacks.