Bug 1732719 (CVE-2019-14249) - CVE-2019-14249 libdwarf: division by zero in dwarf_elf_load_headers.c leading to DoS
Summary: CVE-2019-14249 libdwarf: division by zero in dwarf_elf_load_headers.c leading...
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2019-14249
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1732721 1732720
Blocks: 1754504
TreeView+ depends on / blocked
 
Reported: 2019-07-24 08:13 UTC by Marian Rehak
Modified: 2019-09-29 15:18 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-24 06:45:35 UTC


Attachments (Terms of Use)

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:

https://sourceforge.net/p/libdwarf/code/merge-requests/4/

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?

cvss3=7.5/CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

https://access.redhat.com/security/cve/cve-2019-14249


Note You need to log in before you can comment on or make changes to this bug.