Bug 1677538 (CVE-2019-7665) - CVE-2019-7665 elfutils: heap-based buffer over-read in function elf32_xlatetom in elf32_xlatetom.c
Summary: CVE-2019-7665 elfutils: heap-based buffer over-read in function elf32_xlateto...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-7665
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: impact=low,public=20190112,reported=2...
Depends On: 1679079 1677539 1679078
Blocks: 1677542
TreeView+ depends on / blocked
 
Reported: 2019-02-15 08:00 UTC by Dhananjay Arunesh
Modified: 2019-08-06 13:21 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-06 13:21:58 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2197 None None None 2019-08-06 12:27:16 UTC

Description Dhananjay Arunesh 2019-02-15 08:00:19 UTC
In elfutils 0.175, a heap-based buffer over-read was discovered in the function
elf32_xlatetom in elf32_xlatetom.c in libelf. A crafted ELF input can cause a
segmentation fault leading to denial of service (program crash) because
ebl_core_note does not reject malformed core file notes.

References:
https://sourceware.org/bugzilla/show_bug.cgi?id=24089
https://sourceware.org/ml/elfutils-devel/2019-q1/msg00049.html

Comment 1 Dhananjay Arunesh 2019-02-15 08:00:45 UTC
Created elfutils tracking bugs for this issue:

Affects: fedora-all [bug 1677539]

Comment 3 Mark Wielaard 2019-02-20 13:24:53 UTC
Note that the description of this CVE is somewhat misleading. This can only be triggered running eu-readelf -n on a core file. And the core file needs to have a NT_PLATFORM note with a non-zero terminated string. eu-readelf might then try to process too much data in the note, possibly eventually calling elf_xlatetom on that data. But the bug is not in that library function, it is simply eu-readelf not handling one specific core file note with a non-zero terminated string.

Comment 4 Frank Ch. Eigler 2019-02-20 14:11:13 UTC
I cannot understand why the CVSS3 score includes "AV:H".  There is no service whose availability is impacted.  This is an ordinary program crashing on corrupt input.

Comment 5 Frank Ch. Eigler 2019-02-20 14:23:35 UTC
I meant A:H (thanks mjw)

Comment 6 Dhananjay Arunesh 2019-02-21 04:25:25 UTC
In reply to comment #5:
> I meant A:H (thanks mjw)
As per my understanding I assigned A:H because it causing SEGV resulting in dos, which may lead to complete disruption of service instead of reduced performance or any other interruption.

Comment 7 Mark Wielaard 2019-02-21 11:00:22 UTC
(In reply to Dhananjay Arunesh from comment #6)
> In reply to comment #5:
> > I meant A:H (thanks mjw)
> As per my understanding I assigned A:H because it causing SEGV resulting in
> dos, which may lead to complete disruption of service instead of reduced
> performance or any other interruption.

What is the 'service'?
This really is just a local user running eu-readelf -n on a local core file.

Also does it really SEGV in normal situations? Running the (second) reproducer under valgrind I can see it accesses an uninitialized (but addressable) byte.
When recompiled with the gcc address sanitizer this access turns into a SEGV. But I haven't been able to use any of the reproducers to produce a crash without extra debugging techniques.

I am not denying it isn't a bug (I did fix it upstream already).
But it would be good to know why such a bug gets such a high CVE score.

Comment 8 Dhananjay Arunesh 2019-02-21 12:41:50 UTC
In reply to comment #7:
> (In reply to Dhananjay Arunesh from comment #6)
> > In reply to comment #5:
> > > I meant A:H (thanks mjw)
> > As per my understanding I assigned A:H because it causing SEGV resulting in
> > dos, which may lead to complete disruption of service instead of reduced
> > performance or any other interruption.
> 
> What is the 'service'?
> This really is just a local user running eu-readelf -n on a local core file.
> 
> Also does it really SEGV in normal situations? Running the (second)
> reproducer under valgrind I can see it accesses an uninitialized (but
> addressable) byte.
> When recompiled with the gcc address sanitizer this access turns into a
> SEGV. But I haven't been able to use any of the reproducers to produce a
> crash without extra debugging techniques.
> 
> I am not denying it isn't a bug (I did fix it upstream already).
> But it would be good to know why such a bug gets such a high CVE score.


Hi Mark,
Thanks for the information provided by you, according to the analysis provided by I'd assign A:L.
updated "A:L" and Impact to Low

Comment 9 errata-xmlrpc 2019-08-06 12:27:15 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2019:2197 https://access.redhat.com/errata/RHSA-2019:2197

Comment 10 Product Security DevOps Team 2019-08-06 13:21:58 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-7665


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