oss-sec mailing list archives
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 radarhttps://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 Sebastian
Current thread:
- Re: expat hash collision fix too predictable? Sebastian Pipping (Jun 03)
- Re: expat hash collision fix too predictable? cve-assign (Jun 03)
- Re: Re: expat hash collision fix too predictable? Daniel Micay (Jun 04)
- Re: expat hash collision fix too predictable? Sebastian Pipping (Jun 04)
- Re: expat hash collision fix too predictable? cve-assign (Jun 04)
- Re: expat hash collision fix too predictable? Sebastian Pipping (Jun 04)
- Re: expat hash collision fix too predictable? cve-assign (Jun 03)