Bugzilla – Bug 934119
VUL-1: CVE-2015-9019: libxslt: math.random() in xslt uses unseeded randomness
Last modified: 2022-03-24 00:51:34 UTC
https://git.gnome.org/browse/libxslt/commit/?id=3fcf11ead6ad226227b0a3ef4cc6565b8d5857ff is the mentioned fix I think.
bugbot adjusting priority
Public upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=758400 From a bug report via email (Credit go to Fernando Arnaboldi) The affected products are using a random function that returns a fixed value. Random values are a set of values whose elements that have equal probability of occurrence. In this context, this set of elements is numbers between 0 and 1. The problem lies in that the library returns always the same value since it is not using a random initialization vector. Therefore, without distinction on where is executed (python, php, or with xsltproc), the pattern of values will be always the same. I found the following patch (https://mail.gnome.org/archives/commits-list/2013-February/msg06493.html) related to the random functionality of xsltproc. However, I the random function in libxslt should be the one providing by default a random number. Furthermore, it should use by default an initialization vector and not the other way around. Developers may be using a fixed numbers instead of a "random number from 0 to 1” as the documentation states (http://exslt.org/math/functions/random/index.html).
$ cat random.xml <?xml version="1.0" encoding="ISO-8859-1"?> <?xml-stylesheet type="text/xsl" href="random.xsl"?> <root/> $ cat random.xsl <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:math="http://exslt.org/math" extension-element-prefixes="math"> <xsl:output omit-xml-declaration="yes"/> <xsl:template match="/"> <xsl:value-of select="math:random()" /><xsl:text>
</xsl:text> </xsl:template> </xsl:stylesheet> $ BEFORE (1.2.28) $ xsltproc random.xml random.xsl 0.84018771715471 $ xsltproc random.xml random.xsl 0.84018771715471 $ xsltproc random.xml random.xsl 0.84018771715471 AFTER (1.2.29) $ xsltproc random.xml random.xsl 0.776777266886447 $ xsltproc random.xml random.xsl 0.134103803026538 $ xsltproc random.xml random.xsl 0.494833716887438 $
Commit from comment 1 fixes just xsltproc. For example: $ ldd /usr/lib64/php7/extensions/xsl.so | grep xslt libexslt.so.0 => /usr/lib64/libexslt.so.0 (0x00007f50a0195000) libxslt.so.1 => /usr/lib64/libxslt.so.1 (0x00007f509ff54000 $ rpm -q libxslt1 libxslt1-1.1.29-2.1.x86_64 $ cat test.php <?php $dom = new domDocument; $dom->load("random.xml"); if(!$dom) { echo "Error while parsing the document\n"; exit; } $xsl = new domDocument; $xsl->load("random.xsl"); if(!$xsl) { echo "Error while parsing the document\n"; exit; } $proc = new xsltprocessor; if(!$proc) { echo "Error while making xsltprocessor object\n"; exit; } $proc->importStylesheet($xsl); print "\n"; print $proc->transformToXml($dom); print "\n"; ?> $ php test.php 0.84018771715471 pgajdos@alef:~/work/libxslt/934119[0]> php test.php 0.84018771715471 pgajdos@alef:~/work/libxslt/934119[0]> php test.php 0.84018771715471 $
I do not see any commit message that would indicate progress from 1.1.29. So if I understand correctly, we are waiting for upstream patch -- resolution of https://bugzilla.gnome.org/show_bug.cgi?id=758400 Was a CVE ever requested for this one? I do not see any mail on oss-security@.
Created attachment 719808 [details] libxslt-random-seed.patch set randinit = 1 at the end too
Thanks, it works for me: $ php test.php 0.375211713078996 $ php test.php 0.730786509220855 $ php test.php 0.0944273747012147 $
And thanks for updating the upstream bug.
It might be clear but note that patch from comment 10 obsoletes original upstream commit from comment 1. At least the commit is not needed anymore to make xsltproc on the testcase from comment 6 to return distinct values.
Packages submitted. CVE still not assigned.
I requested a CVE now.
CVE-2015-9019
Created attachment 720053 [details] libxslt-random-seed.patch libxslt-random-seed.patch fixed if condition
Added CVE to the changelog & updated the patch. Packages submitted.
SUSE-SU-2017:1282-1: An update that fixes four vulnerabilities is now available. Category: security (moderate) Bug References: 1005591,1035905,934119,952474 CVE References: CVE-2015-7995,CVE-2015-9019,CVE-2016-4738,CVE-2017-5029 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP4 (src): libxslt-1.1.24-19.33.1, libxslt-python-1.1.24-19.33.3 SUSE Linux Enterprise Server 11-SP4 (src): libxslt-1.1.24-19.33.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): libxslt-1.1.24-19.33.1, libxslt-python-1.1.24-19.33.3
SUSE-SU-2017:1313-1: An update that fixes four vulnerabilities is now available. Category: security (moderate) Bug References: 1005591,1035905,934119,952474 CVE References: CVE-2015-7995,CVE-2015-9019,CVE-2016-4738,CVE-2017-5029 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP2 (src): libxslt-1.1.28-16.1 SUSE Linux Enterprise Software Development Kit 12-SP1 (src): libxslt-1.1.28-16.1 SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): libxslt-1.1.28-16.1 SUSE Linux Enterprise Server 12-SP2 (src): libxslt-1.1.28-16.1 SUSE Linux Enterprise Server 12-SP1 (src): libxslt-1.1.28-16.1 SUSE Linux Enterprise Desktop 12-SP2 (src): libxslt-1.1.28-16.1 SUSE Linux Enterprise Desktop 12-SP1 (src): libxslt-1.1.28-16.1
openSUSE-SU-2017:1390-1: An update that fixes four vulnerabilities is now available. Category: security (moderate) Bug References: 1005591,1035905,934119,952474 CVE References: CVE-2015-7995,CVE-2015-9019,CVE-2016-4738,CVE-2017-5029 Sources used: openSUSE Leap 42.2 (src): libxslt-1.1.28-10.3.1, libxslt-python-1.1.28-10.3.1
fixed
Greetings! Sorry for raising the dead here, but I'd like to reopen this discussion, for clarity sake at least. And that's because of some answers that the upstream bug got that weren't addressed/further discussed, and answers of some downstream bugs of other Linux Distributions too. I'm replicating the aforementioned upstream/downstream answers here: * Starting with upstream GNOME bug (https://bugzilla.gnome.org/show_bug.cgi?id=758400). > Hanno Böck, on 2017-04-06 08:40:10 UTC, has said: > Hi, this just went over oss-security, I'll repost the comments (+ one more > thought I only had after the mail) I posted there here: > 1. What's the use of the random number and what's the security impact > if it's not random? That's not explained. > In case a cryptographically secure random number is required then using > rand()/srand() is a bad idea anyway. > (Unfortunately there's no secure random in the standard libc, but at > least glibc now has getrandom.). > > 2. This part of the patch looks a bit strange: > > + seed = time(NULL); /* just in case /dev/urandom is not there */ > + if (fd == -1) { > + read (fd, &seed, sizeof(seed)); > + close (fd); > + } > > You're calling time() unconditionally, although it's kinda just a > fallback. Why not > + if (fd == -1) { > + read (fd, &seed, sizeof(seed)); > + close (fd); > + } else { > + seed = time(NULL); > + } > ? > > (obviously using time is not a secure way to do random numbers, if > secure numbers are required cross-plattform you need to do this > otherwise anyway) > 3. calling srand() from a library is considered bad practice. > Sometimes applications expect a deterministic behavior of random(). (In other > cases calling srand() unexpectedly was considered a security vuln, see > CVE-2012-6702 in expat) ---------------------------------------------------------------------------------- > John Haxby, on 2020-02-12 12:20:36 UTC, has said: > In the light of the previous comment, would it not make sense to close this as > NOT-A-BUG and, if possible. have CVE-2015-9019 rejected? * Debian bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859796): Bears no replies. * Debian Security Tracker ticket for CVE-2015-9019 (https://security-tracker.debian.org/tracker/CVE-2015-9019) with an anonymous note: > There's no indication that math.random() in intended to ensure cryptographic > randomness requirements. Proper seeding needs to happen in the application > using libxslt. * Red Hat bug (https://bugzilla.redhat.com/show_bug.cgi?id=1439548 closed as WONTFIX): > Doran Moppert, on 2017-04-11 03:29:54 UTC, has said: > Statement: > The xslt random function provided by libxslt does not offer any security or cryptography > guarantees. Applications using libxslt that rely on non-repeatable randomness should be > seeding the system PRNG (srand()) themselves, as they would if calling rand() directly. My searches didn't return anything for other major distributions. Apparently only openSUSE and Mageia are addressing this CVE with patches. So should we still carry around our patch, really, even though other downstream distributions dismissed a fix in libxslt, and rather pointed that projects using it should be the ones taking care of the proper seeding? If so I'd like to, at least, add the "PATCH-FIX-OPENSUSE" tag to the spec file (currently it doesn't have any comments with reasoning, bug ID, or whether it's an UPSTREAM/OPENSUSE/SUSE patch).