User: Password:
|
|
Subscribe / Log in / New account

Security

Python vulnerability disclosure

By Jake Edge
April 27, 2011

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:

To me, the fix *was* released. Sure, no fancy installers were generated yet, but people who are susceptible to this issue 1) now know about it, and 2) have a way to patch their system *if needed*.

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:

The code is open source: Anyone watching the commits/list know that this issue was fixed. It's better to keep it in the public's eyes, so they know *something was fixed and they should patch* than to rely on people *not* watching these channels.

Assume the bad guys already knew about the exploit: We have to spread the knowledge of the fix as far and as wide as we can so that people even know there is an issue, and that it was fixed. This applies to users and *vendors* as well.

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:

Also, I think Gustavo's whole point is that if we don't have a well-defined, deterministic procedure for security announcements and releases, then it's just as though we didn't care about security at all. Saying "look, we mentioned this one on our development blog" isn't really reassuring for the target group of people.

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.

Comments (3 posted)

Brief items

Security quote of the week

Under the proposed approach, a covert channel is used to encode the sensitive information by modifying the fragmentation patterns in the cluster distribution of an existing file. As opposed to existing schemes, the proposed covert channel does not require storage of any additional information on the filesystem. Moreover, the channel provides two-fold plausible deniability so that an investigator without the key cannot prove the presence of hidden information.
-- from the abstract of Designing a cluster-based covert channel to evade disk investigation and forensics

Comments (1 posted)

Android phones keep location cache, too, but it's harder to access (ars technica)

After the recent discovery that iPhones/iPads were recording location data on the device, folks have been looking for similar data on Android phones—and have now found some. "Another important difference, according to developer Mike Castelman, is that Android keeps less data overall than iOS devices. 'The main difference that I can see is that Android seems to have a cache versus iOS's log,' Castleman, who contributed some code improvements to [Magnus] Eriksson's tool, told Ars. That is, Android appears to limit the caches to 50 entries for cell tower triangulation and 200 entries for WiFi basestation location. iOS's consolidated.db, on the other hand, seems to keep a running tally of data since iOS is first installed and activated on a device. iOS will also keep multiple records of the same tower or basestation, while Android only keeps a single record."

Comments (15 posted)

New vulnerabilities

asterisk: denial of service and code execution

Package(s):asterisk CVE #(s):CVE-2011-1147 CVE-2011-1507 CVE-2011-1599
Created:April 27, 2011 Updated:May 17, 2011
Description: The asterisk telephony system suffers from one denial of service vulnerability (CVE-2011-1507), one remote code execution vulnerability (CVE-2011-1147), and one local privilege escalation problem (CVE-2011-1599).
Alerts:
Gentoo 201110-21 asterisk 2011-10-24
Debian DSA-2225-1 asterisk 2011-04-25
Fedora FEDORA-2011-6225 asterisk 2011-04-29
Fedora FEDORA-2011-6208 asterisk 2011-04-29

Comments (none posted)

fail2ban: conflicts with selinux

Package(s):fail2ban CVE #(s):
Created:April 26, 2011 Updated:April 27, 2011
Description: From the Fedora advisory:

fail2ban used predictable /tmp files which a local user can allocate before fail2ban does. All tmp files have been moved to /var/lib/fail2ban. This also helps with selinux policies.

Another security related fix is that fail2ban defaulted to gamin which conflicts with selinux, so users had to typically choose between fail2ban and selinux. fail2ban now defaults to inotify (thanks to Jonathan Underwood).

Alerts:
Fedora FEDORA-2011-5151 fail2ban 2011-04-10
Fedora FEDORA-2011-5153 fail2ban 2011-04-10

Comments (none posted)

perl: arbitrary command execution

Package(s):perl CVE #(s):CVE-2011-1487
Created:April 25, 2011 Updated:June 21, 2011
Description: From the Red Hat bugzilla:

A security flaw was found in the way Perl performed laundering of tainted data. A remote attacker could use this flaw to bypass Perl TAINT mode protection mechanism (leading to commands execution on dirty arguments or file system access via contaminated variables) via specially-crafted input provided to the web application / CGI script.

Alerts:
Gentoo 201311-17 perl 2013-11-28
Debian DSA-2265-1 perl 2011-06-20
Pardus 2011-72 perl 2011-05-02
Ubuntu USN-1129-1 perl 2011-05-03
Red Hat RHSA-2011:0558-01 perl 2011-05-19
Fedora FEDORA-2011-4918 perl 2011-04-06
SUSE SUSE-SR:2011:009 mailman, openssl, tgt, rsync, vsftpd, libzip1/libzip-devel, otrs, libtiff, kdelibs4, libwebkit, libpython2_6-1_0, perl, pure-ftpd, collectd, vino, aaa_base, exim 2011-05-17
openSUSE openSUSE-SU-2011:0479-1 perl 2011-05-13
Mandriva MDVSA-2011:091 perl 2011-05-18

Comments (none posted)

rdesktop: directory traversal

Package(s):rdesktop CVE #(s):CVE-2011-1595
Created:April 22, 2011 Updated:October 19, 2012
Description: From the Slackware advisory:

Patched a traversal vulnerability (disallow /.. requests).

Alerts:
Gentoo 201210-03 rdesktop 2012-10-18
Fedora FEDORA-2011-7697 rdesktop 2011-05-30
Fedora FEDORA-2011-7694 rdesktop 2011-05-30
Fedora FEDORA-2011-7688 rdesktop 2011-05-30
SUSE SUSE-SR:2011:010 postfix, libthunarx-2-0, rdesktop, python, viewvc, kvm, exim, logrotate, dovecot12/dovecot20, pure-ftpd, kdelibs4 2011-05-31
Mandriva MDVSA-2011:102 rdesktop 2011-05-28
Ubuntu USN-1136-1 rdesktop 2011-05-25
openSUSE openSUSE-SU-2011:0530-1 rdesktop 2011-05-24
CentOS CESA-2011:0506 rdesktop 2011-05-12
Red Hat RHSA-2011:0506-01 rdesktop 2011-05-11
Pardus 2011-69 rdesktop 2011-05-02
Slackware SSA:2011-110-01 rdesktop 2011-04-22
openSUSE openSUSE-SU-2011:0528-1 rdesktop 2011-05-24

Comments (none posted)

tinyproxy: access restriction bypass

Package(s):tinyproxy CVE #(s):CVE-2011-1499
Created:April 21, 2011 Updated:September 23, 2013
Description:

From the Debian advisory:

Christoph Martin discovered that incorrect ACL processing in TinyProxy, a lightweight, non-caching, optionally anonymizing http proxy could lead to unintended network access rights.

Alerts:
Fedora FEDORA-2013-16225 tinyproxy 2013-09-21
Debian DSA-2222-1 tinyproxy 2011-04-20

Comments (none posted)

wireshark: two buffer overflows

Package(s):wireshark CVE #(s):CVE-2011-1590 CVE-2011-1591
Created:April 27, 2011 Updated:July 8, 2011
Description: The wireshark protocol analyzer suffers from buffer overflows (possibly leading to remote code execution vulnerabilities) in the x.509if and DECT dissectors.
Alerts:
Oracle ELSA-2013-1569 wireshark 2013-11-26
CentOS CESA-2012:0509 wireshark 2012-04-24
Oracle ELSA-2012-0509 wireshark 2012-04-23
Scientific Linux SL-wire-20120423 wireshark 2012-04-23
Red Hat RHSA-2012:0509-01 wireshark 2012-04-23
Gentoo 201110-02 wireshark 2011-10-09
Debian DSA-2274-1 wireshark 2011-07-07
openSUSE openSUSE-SU-2011:0602-1 wireshark 2011-06-07
openSUSE openSUSE-SU-2011:0599-1 wireshark 2011-06-07
Pardus 2011-77 wireshark 2011-05-26
Fedora FEDORA-2011-5569 wireshark 2011-04-19
Fedora FEDORA-2011-5529 wireshark 2011-04-18
Mandriva MDVSA-2011:083 wireshark 2011-05-12

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds