Bugzilla – Bug 983215
VUL-1: CVE-2012-6702: expat: XML_Parse breaks rand() function
Last modified: 2018-10-04 14:40:38 UTC
via oss-sec from mitre The call to srand(3) can reduce the security of the calling application, depending on what it is doing with srand(3)/random(3). This behavior is recognized as a bug by Fedora, too (https://bugzilla.redhat.com/show_bug.cgi?id=1197087). The text below assigns one CVE ID to this expat vulnerability. https://bugzilla.redhat.com/show_bug.cgi?id=1197087#c6 Expat is calling srand ... [if] the code using Expat ... never called XML_SetHashSalt on that parser ... the arrival of XML_SetHashSalt bypassed the Expat user's radar https://sourceforge.net/p/expat/bugs/499/ 2012-04-05 In any case, you can supply your own hash salt - after creating the parser, but before parsing is started. See the new API function XML_SetHashSalt. The higher-level issue, from our perspective, is that a library (intended for use in arbitrary applications) should not have potentially unavoidable calls to the srand function unless this is documented. The library might be used by an application in which srand was already called exactly once, and srand/rand happens to be the right choice for that application because of a minimal need for randomness, and this minimal need for randomness is no longer satisfied if there are unexpected extra calls to srand. In other words, good options for a library include: - never call srand under any circumstances - call srand only if the application calls a library function that is documented as triggering an srand call - call srand whenever it wants, as long as the documentation warns application authors about potential incompatibility with any use of srand within an application We really don't know whether the above is a generally accepted principle for all libraries. However, it appears that the expat vendor is recognizing the old behavior (i.e., the behavior before XML_SetHashSalt was available and documented) as a security-relevant implementation error. Use CVE-2012-6702. An entirely separate question is whether generate_hash_secret_salt should ultimately be using the rand function to attempt to provide a random number, or whether it should provide a better quality random number. There is no CVE ID for this yet. If the expat upstream maintainer is announcing a new expat release, specifically stating that discontinuing use of the rand function represents a vulnerability fix, then a CVE ID can be assigned. One might make a design assertion that every portable library and application, if it potentially has a need for good random numbers, is supposed to have its own code that is able to call each of getrandom, CryptGenRandom, and arc4random_buf on the applicable OS (as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1197087#c28). We don't feel that CVE is the right way to track that assertion's viability or adherence. References: https://bugzilla.redhat.com/show_bug.cgi?id=1319731 https://bugzilla.redhat.com/show_bug.cgi?id=1197087 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-6702 http://seclists.org/oss-sec/2016/q2/469 http://seclists.org/oss-sec/2016/q2/472
Re: expat hash collision fix too predictable? From: Sebastian Pipping <sebastian () pipping org> Date: Sat, 4 Jun 2016 16:17:28 +0200 Hi! On 04.06.2016 04:56, cve-assign () mitre org wrote: The text below assigns one CVE ID to this expat vulnerability. Thank you. Please see my questions below. https://bugzilla.redhat.com/show_bug.cgi?id=1197087#c6 Expat is calling srand ... [if] the code using Expat ... never called XML_SetHashSalt on that parser ... the arrival of XML_SetHashSalt bypassed the Expat user's radar https://sourceforge.net/p/expat/bugs/499/ 2012-04-05 In any case, you can supply your own hash salt - after creating the parser, but before parsing is started. See the new API function XML_SetHashSalt. The higher-level issue, from our perspective, is that a library (intended for use in arbitrary applications) should not have potentially unavoidable calls to the srand function unless this is documented. The library might be used by an application in which srand was already called exactly once, and srand/rand happens to be the right choice for that application because of a minimal need for randomness, and this minimal need for randomness is no longer satisfied if there are unexpected extra calls to srand. In other words, good options for a library include: - never call srand under any circumstances - call srand only if the application calls a library function that is documented as triggering an srand call - call srand whenever it wants, as long as the documentation warns application authors about potential incompatibility with any use of srand within an application We really don't know whether the above is a generally accepted principle for all libraries. Agreed. However, it appears that the expat vendor is recognizing the old behavior (i.e., the behavior before XML_SetHashSalt was available and documented) as a security-relevant implementation error. Use CVE-2012-6702. An entirely separate question is whether generate_hash_secret_salt should ultimately be using the rand function to attempt to provide a random number, or whether it should provide a better quality random number. There is no CVE ID for this yet. If the expat upstream maintainer is announcing a new expat release, specifically stating that discontinuing use of the rand function represents a vulnerability fix, then a CVE ID can be assigned. I am not sure if I get that right. The hash DoS vulnerability CVE-2012-0876 was fixed to some extend in Expat 2.1.0, commit e3e81a6d -- the place where Expat started calling srand. While XML_SetHashSalt was introducd a bit later, it did arrive with Expat 2.1.0 still. srand was called (by generate_hash_secret_salt) since Expat 2.1.0 if a) the app using Expat did not call XML_SetHashSalt prior to starting to parse with that XML_Parser instance (XML_SetHashSalt existing or not) or b) the app using Expat called XML_SetHashSalt with hash_salt of value 0 (which is documented since Expat 2.1.1, commit 891ec14f). The next release of Expat will not do internal calls to srand (or rand) any more but extract and use entropy from other sources. Please confirm that using CVE-2012-6702 for consequences of "unanticipated internal calls to srand" is what you intended. Also I suppose hash initialization with (too little /) second-based entropy still is part of the original CVE-2012-0876 (or the same again). If not, it may not fit CVE-2012-6702 semantically. Thank you! Best
bugbot adjusting priority
This is an autogenerated message for OBS integration: This bug (983215) was mentioned in https://build.opensuse.org/request/show/441164 Factory / expat
An update workflow for this issue was started. This issue was rated as moderate. Please submit fixed packages until 2017-02-16. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/63374
SUSE-SU-2017:0415-1: An update that solves two vulnerabilities and has one errata is now available. Category: security (moderate) Bug References: 1022037,983215,983216 CVE References: CVE-2012-6702,CVE-2016-5300 Sources used: SUSE Studio Onsite 1.3 (src): expat-2.0.1-88.41.1 SUSE Linux Enterprise Software Development Kit 11-SP4 (src): expat-2.0.1-88.41.1 SUSE Linux Enterprise Server 11-SP4 (src): expat-2.0.1-88.41.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): expat-2.0.1-88.41.1
SUSE-SU-2017:0424-1: An update that fixes two vulnerabilities is now available. Category: security (moderate) Bug References: 983215,983216 CVE References: CVE-2012-6702,CVE-2016-5300 Sources used: SUSE Linux Enterprise Software Development Kit 12-SP2 (src): expat-2.1.0-20.2 SUSE Linux Enterprise Software Development Kit 12-SP1 (src): expat-2.1.0-20.2 SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src): expat-2.1.0-20.2 SUSE Linux Enterprise Server 12-SP2 (src): expat-2.1.0-20.2 SUSE Linux Enterprise Server 12-SP1 (src): expat-2.1.0-20.2 SUSE Linux Enterprise Desktop 12-SP2 (src): expat-2.1.0-20.2 SUSE Linux Enterprise Desktop 12-SP1 (src): expat-2.1.0-20.2
openSUSE-SU-2017:0483-1: An update that fixes two vulnerabilities is now available. Category: security (moderate) Bug References: 983215,983216 CVE References: CVE-2012-6702,CVE-2016-5300 Sources used: openSUSE Leap 42.2 (src): expat-2.1.0-19.1 openSUSE Leap 42.1 (src): expat-2.1.0-20.1
released