[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5752E2F8.10805@pipping.org>
Date: Sat, 4 Jun 2016 16:17:28 +0200
From: Sebastian Pipping <sebastian@...ping.org>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: expat hash collision fix too predictable?
Hi!
On 04.06.2016 04:56, cve-assign@...re.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
Sebastian
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
