Bug 1732719 (CVE-2019-14249)

Summary: CVE-2019-14249 libdwarf: division by zero in dwarf_elf_load_headers.c leading to DoS
Product: [Other] Security Response Reporter: Marian Rehak <mrehak>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: fche, jitesh.1337, orion
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-09-24 06:45:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1732720, 1732721    
Bug Blocks: 1754504    

Description Marian Rehak 2019-07-24 08:13:58 UTC
dwarf_elf_load_headers.c in libdwarf before 2019-07-05 allows attackers to cause a denial of service (division by zero) via an ELF file with a zero-size section group (SHT_GROUP), as demonstrated by dwarfdump.

Upstream patch:


Comment 1 Marian Rehak 2019-07-24 08:14:16 UTC
Created libdwarf tracking bugs for this issue:

Affects: epel-6 [bug 1732721]
Affects: fedora-all [bug 1732720]

Comment 2 Frank Ch. Eigler 2019-07-24 10:49:23 UTC
Can someone suggest a mechanism by which this libdwarf bug can result in anything bad to a system?  Is there a privileged system service that takes untrusted dwarf input?  What justifies this high CVSS3 rating?


Comment 3 Tom Hughes 2019-07-24 10:54:43 UTC
I'm sorry, you expected a CVE to make some sense?

Just ignore it - as and when there's a new release that fixes it I'll close all the duplicate bugs that were opened this morning.

Comment 5 Tom Hughes 2019-07-29 14:55:46 UTC
What information are you asking him to provide? He's just copy and pasting CVEs into bugs and won't know anything specific about this bug.

Comment 6 Frank Ch. Eigler 2019-07-29 19:42:47 UTC
CVSS severity scores are normally computed by RH folks, based upon the actual exposure/configuration of the buggy software in the distribution.  I'm not quibbling about the text.  I'm wondering what reason we have to believe that this is a high-impact (7.5) problem in RHEL.

Comment 7 Marian Rehak 2019-07-30 08:29:30 UTC
What I see is a crash caused by division by zero(that's the information I can work with within the little time I can spend on issues like these) leading to the whole affected component not working. By the definition of this[0] that means Availability impact high. If you have any justification as to why the impact score should be lower in case of RH product please do share. As I am not a platform specialist, please understand that I can not see into these things as good as perhaps you can. If you were to explain why the score is too high, we could lower it based on that justification(for future references, when a customer asks about CVSS inconsistencies between companies, which tends to happen)...

[0]    https://www.first.org/cvss/user-guide#5-8-Availability-Impact-Rubric

Comment 8 Frank Ch. Eigler 2019-07-30 11:17:01 UTC
"What I see is a crash caused by division by zero [...] leading to the whole affected component not working"

We do not normally consider a "component" to be a short lived, manually invoked, unprivileged, short, batch-oriented program, but closer to the category of network servers, or other long-running programs whose failure has some sort of actual impact.

By defining "component" so far down, practically any failure or error can be marked as serious.  That in turn crowds out actual serious problems.  I am assuming the RH Security folks already have some guidance like this somewhere - but if not, it is badly needed.

Comment 9 Doran Moppert 2019-09-24 04:08:54 UTC
I have revised the CVSS score to be more realistic.  The initial score came from MITRE/NVD and had not yet been examined by Product Security analysts.

As a general rule, we need to treat libraries as though they may be linked to server processes and exposed to network input so AV:N is the default.  That's not how libdwarf is used in any applications we ship, nor is it likely to be useful for third-party applications to do so, at least without significant other security controls in place.  The re-rating is based on typical/known uses of libdwarf.

Comment 11 Product Security DevOps Team 2019-09-24 06:45:35 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):