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/
Created libdwarf tracking bugs for this issue: Affects: epel-6 [bug 1732721] Affects: fedora-all [bug 1732720]
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
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.
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.
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.
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
"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.
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.
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