Python vulnerability disclosure

Vulnerability disclosure is often a bit tricky. There are those who would like to see the information closely held until updated packages are available for most users, while others prefer to see users get information about a security hole more quickly. Because free software development takes place in the open, with publicly accessible code repositories, it makes it that much harder to completely bottle up information about those holes. A recent discussion on the python-dev mailing list highlights the problem well.

A bug in Python's urllib and urllib2 URL handling libraries was fixed by Guido van Rossum in late March. The problem was fairly straightforward, but did have security implications. Basically, those libraries were not properly sanitizing HTTP redirects, which allowed redirects to URL schemes other than http://, https://, and ftp://. In particular, the bug report notes that a redirection to file:///etc/passwd could potentially improperly disclose the contents of that file. Other misuses are possible as well.

The fix led to a posting by Brian Curtin on the Python development blog. The posting described the problem and the fix, along with some useful information on reporting Python security flaws. It also noted that an updated version of Python 2.5 would be coming soon, but that maintenance releases for 2.6, 2.7, 3.1, and 3.2 had yet to be scheduled.

Gustavo Narea expressed concerns about the posting, though, wondering why the vulnerability was being disclosed prior to updated packages being available: "My understanding is that the whole point of asking people not to report security vulnerability publicly was to allow time to release a fix." But, as several people pointed out in the thread, once a fix has been committed to a public repository—and a public bug report is created—there is nothing to be gained by keeping the vulnerability "secret". Curtin replied to Narea to that effect:

Jesse Noller was even more explicit, noting that the "bad guys" likely already know about the vulnerability, and that publicity is exactly what is needed:

Whether or not Python puts out an immediate release to address the issue, it is important that users get the information they need to make a decision about how (or whether) to address the problem. Without that knowledge, it may well be that the only people who know about it (outside of those working on a fix) are the ones likely to try to exploit it. In essence, this comes down to the age-old split between those who advocate "full disclosure" and those who believe that "responsible disclosure" (or some other disclosure policy) is the right way to go.

The boundaries between full and responsible disclosure become a bit fuzzy in the free software world. Certainly any "bad guys" that follow the Python development tree would have noted the fix going in well before the announcement was made. Waiting to disclose it until a release is done would obviously just make that worse. But, not committing the fix until a release is ready is also untenable. In the end, free software projects, by their very nature, are better off being toward the "full disclosure" end of the axis.

A related question that came up in the discussion was about how the information about the vulnerability was disseminated. There is currently no "official" channel for Python to publicize any vulnerabilities that arise. Clearly Curtin's blog post helped get the word out, but without an official channel (like the distribution security announcement lists), it may have been something of a hit-or-miss approach. As Antoine Pitrou put it:

The vulnerability has already been assigned CVE-2011-1521, which is just a reserved entry, currently, but others have associated it with the urllib flaws. So there are multiple ways for bad or good guys to find out about the problem, but none that are officially associated with the Python project. This particular vulnerability may not be serious enough to force a "drop everything and push out a release" fire drill, but others may be. Distributions and others interested should have a way to be informed of these kinds of flaws that doesn't involve closely following the commits, CVEs, or the development blog.

The consensus in the thread, at least, seemed in favor of a security-announce kind of list for Python. Though Narea's original email concerned premature release of the vulnerability information, the end result of the discussion was that the information was probably not disseminated widely enough. Other projects may want to consider this discussion when formulating their own security vulnerability disclosure plans.