Date: Fri, 3 Jun 2016 22:56:47 -0400 (EDT) From: cve-assign@...re.org To: sebastian@...ping.org Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: expat hash collision fix too predictable? -----BEGIN PGP SIGNED MESSAGE----- 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 > (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. - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJXUkL1AAoJEHb/MwWLVhi29JcP/1O68QOg+teOsPnIAXqBFnf+ 8zty+w4jemQtwcSeSEsFKm7U9r3ACC/EtGi8sdjws5kqFY7Qad2+XyJS4mTQLozZ aK2MjByk3ITmEtPkLiIwBbYro1DpixvdOnkCVGUKe3NwuZ42/FOnXNobPprSEBPW 5ibjiqcu1HKAfH7A2e9EuGs63Skdh40NhEBwSbbvhiHLq1FMQuETEGmkno7yIC+u zijg1uz+K//YkJrADyzvAzwcfer4WUqe9Ney+jgrTyp5sIqVuStro08WVH7HQRTZ pKJ4ZbvNrn0HrchA5nd+xcsn7B29NjKMVuUCvczpP4xZKvASyey95+t9FfrkwZ6O A04BdefJMddedSwd7odzVq0QdqUinkWMLlPuMv4UdZRwjF/MsdBqDZVPDouNSPxT vL6KOwhGJ12qazXYhjIDxkqztj6ou9udcUyUsLK0EehlnHeE2/ZnfnEAR34i53uG wFmPXual8A5imxVtY3uruVl91Y2UAbspTIujSBZcZwBGnIGdXmTBHdybKI4/4dfh 5nsAc6EgVak1hWR/JxzNnvwowySXECLV9XHlaMdzO/g6kMF3HKCGZYhdjgrhIE8b GkN6uKv3JVZmFmuaOvqzPRpkrCS4Y36K9KV+T9u1qGKsmEzUt23vAEU7yr4crlDz cX0LtknjCbvm/N/Hv1eJ =5Ppg -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ