Description of problem: There are serveral problems with the way Jython creates class cache files, potentially leading to arbitrary code execution or information disclosure. # (umask 000; jython -c 'import xmllib') # ls -l '/usr/share/jython/Lib/xmllib$py.class' -rw-rw-rw-. 1 root root 52874 Apr 3 17:24 /usr/share/jython/Lib/xmllib$py.class Jython does not explicitly set permissions of the class files; therefore with weak umask it creates world-writable files, or discloses sensitive data that would be in a non-world-readable package file. Also, the package writes to /usr/share, which it shouldn't; /var/cache would be more appropriate, but would still lead to a possibility of a content disclosure. The only really portable and secure way to cache class files would be a directory in user's home with 0700 permissions. It is currently even not possible to easily disable the caching, since the configuration file is not marked with %config and resides in /usr/share instead of /etc. Version-Release number of selected component (if applicable): jython-2.2.1-4.8.el6.x86_64
Created attachment 731250 [details] [PATCH 1/3] Make cache not accessible by anyone else
Created attachment 731251 [details] [PATCH 2/3] Avoid code duplication with makeCompiledFilename()
Created attachment 731252 [details] [PATCH 3/3] Use cache dir for classes too
Filed this upstream as http://bugs.jython.org/msg8004
I'm wondering if this ticket could be made public, so that I could point Fedora package maintainer(s) to this in order to have this fixed for Fedora/EPEL? The issue seems reported publicly [1] if I understand correctly? (though the CVE number is still not public). [1] http://bugs.jython.org/msg8004
This is now public http://arm.koji.fedoraproject.org/koji/fileinfo?rpmID=1184767&filename=jython-CVE-2013-2027.patch
(In reply to Lubomir Rintel (GoodData, inactive) from comment #2) > Created attachment 731250 [details] > [PATCH 1/3] Make cache not accessible by anyone else That patch looks like it's effectively a no-op, and indeed, one of our QA testers in Mageia tried jython with the same patches Fedora used for this, and found that the ~/.jython and below permissions are unrestricted [1]. Unless the user does a chmod o-x on their home directory, this fix is completely ineffective. [1] - https://bugs.mageia.org/show_bug.cgi?id=15275#c6
(In reply to David Walser from comment #11) > (In reply to Lubomir Rintel (GoodData, inactive) from comment #2) > > Created attachment 731250 [details] > > [PATCH 1/3] Make cache not accessible by anyone else > > That patch looks like it's effectively a no-op, and indeed, one of our QA > testers in Mageia tried jython with the same patches Fedora used for this, > and found that the ~/.jython and below permissions are unrestricted [1]. > Unless the user does a chmod o-x on their home directory, this fix is > completely ineffective. > > [1] - https://bugs.mageia.org/show_bug.cgi?id=15275#c6 Not really. > If you set a weak umask, maybe you deserve what you get. https://bugs.mageia.org/show_bug.cgi?id=15275#c10 If anyone wishes to harden the patch further, please do. I'm not going to do that -- the upstream is unresponsive and I no longer use the package.
This issue appears as fixed, but there is no "Fixed In Version" info and I was not able to search a commit related to this fix. Could you tell me what is/will be the version where this fix will be include? Thanks
Statement: This issue affects the versions of jython as shipped with Red Hat Enterprise Linux version 5 and 6. Red Hat Product Security has rated this issue as having Low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.