Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri,  3 Jun 2016 22:56:47 -0400 (EDT)
Subject: Re: expat hash collision fix too predictable?

Hash: SHA256

> 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
> (

The text below assigns one CVE ID to this expat vulnerability.

>> 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

>>> 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 We don't
feel that CVE is the right way to track that assertion's viability or

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


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.