A CVE has been assigned for a security issue in python-jinja2: http://openwall.com/lists/oss-security/2014/01/10/2 http://openwall.com/lists/oss-security/2014/01/10/3 Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
Advisory: ======================== Updated python-jinja2 packages fix security vulnerability: Jinja2, a template engine written in pure python, was found to use /tmp as a default directory for jinja2.bccache.FileSystemBytecodeCache, which is insecure because the /tmp directory is world-writable and the filenames used like 'FileSystemBytecodeCache' are often predictable. A malicious user could exploit this bug to execute arbitrary code as another user. References: http://openwall.com/lists/oss-security/2014/01/10/2 http://openwall.com/lists/oss-security/2014/01/10/3 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734747 https://bugzilla.redhat.com/show_bug.cgi?id=1051421 ======================== Updated packages in core/updates_testing: ======================== python-jinja2-2.5.5-8.1.mga3.noarch from python-jinja2-2.5.5-8.1.mga3.src Freeze push asked for python-jinja2-2.7.2-1.mga4.src that produce python-jinja2-2.7.2-1.mga4.noarch and python3-jinja2-2.7.2-1.mga4.noarch
Assignee: makowski.mageia => qa-bugs
python-jinja2-2.7.2-1.mga4.noarch and python3-jinja2-2.7.2-1.mga4.noarch are now in mga4 Cauldron
CC: (none) => makowski.mageia
Version: Cauldron => 3Whiteboard: MGA3TOO => (none)
Looks good, thanks Philippe! Note to QA: just make sure to include the (CVE-2014-1402) in the advisory.
Philippe, what fix did you use for CVE-2014-1402? The upstream fix for it introduced another tmpfile security vulnerability that's been assigned CVE-2014-0012: http://openwall.com/lists/oss-security/2014/01/11/1
(In reply to David Walser from comment #4) > Philippe, what fix did you use for CVE-2014-1402? The upstream fix for it > introduced another tmpfile security vulnerability that's been assigned > CVE-2014-0012: > http://openwall.com/lists/oss-security/2014/01/11/1 The Upstream one, like Debian did so yes we are affected by CVE-2014-0012
adding feedback marker for now
Whiteboard: (none) => feedback
I will follow Debian and will apply their patch : http://patch-tracker.debian.org/patch/series/view/jinja2/2.7.2-2/fix_CVE-2014-0012.patch
Advisory: ======================== Updated python-jinja2 packages fix security vulnerability: Jinja2, a template engine written in pure python, was found to use /tmp as a default directory for jinja2.bccache.FileSystemBytecodeCache, which is insecure because the /tmp directory is world-writable and the filenames used like 'FileSystemBytecodeCache' are often predictable. A malicious user could exploit this bug to execute arbitrary code as another user. fix CVE-2014-0012 and CVE-2014-1402 References: http://openwall.com/lists/oss-security/2014/01/10/2 http://openwall.com/lists/oss-security/2014/01/10/3 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734747 https://bugzilla.redhat.com/show_bug.cgi?id=1051421 ======================== Updated packages in core/updates_testing: ======================== python-jinja2-2.5.5-8.2.mga3.noarch from python-jinja2-2.5.5-8.2.mga3.src Freeze push asked for python-jinja2-2.7.2-2.mga4.src that produce python-jinja2-2.7.2-2.mga4.noarch and python3-jinja2-2.7.2-2.mga4.noarch
Whiteboard: feedback => (none)
Created attachment 4847 [details] test.py $ python test.py Hello. If you see this with no errors then it worked :)
Testing mga3 64 There is a PoC attached to the debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734747 I can't make it print moo, can verify (with strace) it is accessing the predicted file in /tmp though and uses an unpredictable dir name in /tmp with the update. Before ------ open("/tmp/__jinja2_0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33.cache", O_RDONLY) = 3 After ----- mkdir("/tmp/jinja2-cache-vqrYjz", 0700) = 0 open("/tmp/jinja2-cache-vqrYjz/__jinja2_0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/tmp/jinja2-cache-vqrYjz/__jinja2_0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33.cache", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 Tested with the PoC, the test.py above and some examples from jinja2 git https://github.com/mitsuhiko/jinja2/tree/master/examples/basic All seem to behave as expected.
Whiteboard: (none) => has_procedure mga3-64-ok
Testing complete mga3 32, test.py and POC
CC: (none) => stormiWhiteboard: has_procedure mga3-64-ok => has_procedure mga3-64-ok mga3-32-ok
Advisory uploaded. David you may want to give it your finishing touch. Validating. Could sysadmin push from 3 core/updates_testing to updates, after the cauldron freeze push though please. Thanks
Keywords: (none) => validated_updateWhiteboard: has_procedure mga3-64-ok mga3-32-ok => has_procedure advisory mga3-64-ok mga3-32-okCC: (none) => sysadmin-bugs
Philippe's advisory is fine, but it should only mention CVE-2014-1402, as that's the only one that effects the previous version in Mageia 3. Stylistically we generally just put the CVE number in parentheses at the end of the description paragraph. Also noting that this needs to be pushed in Cauldron too before this update is pushed onto the mirrors for Mageia 3.
Updated, thanks.
python-jinja2-2.7.2-2.mga4 uploaded for Cauldron.
Update pushed: http://advisories.mageia.org/MGASA-2014-0028.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
URL: (none) => http://lwn.net/Vulnerabilities/582705/
Fedora has issued an advisory for this on June 10: https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134654.html They updated to 2.7.3, which apparently fixes a regressions (and another possible security issue) caused by the fix in 2.7.2. I'm not sure if we're affected...
(In reply to David Walser from comment #17) > Fedora has issued an advisory for this on June 10: > https://lists.fedoraproject.org/pipermail/package-announce/2014-June/134654. > html > > They updated to 2.7.3, which apparently fixes a regressions (and another > possible security issue) caused by the fix in 2.7.2. I'm not sure if we're > affected... I guess I should learn to read. We already addressed that in this bug.
For the same of completeness, LWN reference for CVE-2014-0012: http://lwn.net/Vulnerabilities/610419/