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...
Status: NEW
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...
Keywords: Security
Depends On: 1679078 1679079 1677539
Blocks: 1677542
TreeView+ depends on / blocked
 
Reported: 2019-02-15 08:00 UTC by Dhananjay Arunesh
Modified: 2019-05-03 11:14 UTC (History)
13 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)

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


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