Bug 983215 - (CVE-2012-6702) VUL-1: CVE-2012-6702: expat: XML_Parse breaks rand() function
(CVE-2012-6702)
VUL-1: CVE-2012-6702: expat: XML_Parse breaks rand() function
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P4 - Low : Normal
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/169787/
CVSSv2:RedHat:CVE-2012-6702:4.3:(AV:N...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-06 08:59 UTC by Marcus Meissner
Modified: 2018-10-04 14:40 UTC (History)
2 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2016-06-06 08:59:36 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
Comment 1 Marcus Meissner 2016-06-06 09:00:35 UTC
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
Comment 2 Swamp Workflow Management 2016-06-06 22:00:42 UTC
bugbot adjusting priority
Comment 4 Bernhard Wiedemann 2016-11-21 11:00:32 UTC
This is an autogenerated message for OBS integration:
This bug (983215) was mentioned in
https://build.opensuse.org/request/show/441164 Factory / expat
Comment 6 Swamp Workflow Management 2017-02-02 16:11:17 UTC
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
Comment 7 Swamp Workflow Management 2017-02-07 17:15:09 UTC
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
Comment 8 Swamp Workflow Management 2017-02-08 17:09:14 UTC
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
Comment 9 Swamp Workflow Management 2017-02-17 03:15:25 UTC
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
Comment 10 Marcus Meissner 2017-03-02 14:06:48 UTC
released