Bug 1677538 (CVE-2019-7665)

Summary: CVE-2019-7665 elfutils: heap-based buffer over-read in function elf32_xlatetom in elf32_xlatetom.c
Product: [Other] Security Response Reporter: Dhananjay Arunesh <darunesh>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: abhgupta, apmukher, dbaker, drepper, fche, jakub, jokerman, mjw, mjw, pmachata, sthangav, trankin
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=low,public=20190112,reported=20190211,source=cve,cvss3=3.3/CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L,cwe=CWE-122,fedora-all/elfutils=affected,rhel-5/elfutils=wontfix,rhel-6/elfutils=wontfix,rhel-7/elfutils=affected,rhel-8/elfutils=affected,openshift-online-3/elfutils=notaffected
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 1679078, 1679079, 1677539    
Bug Blocks: 1677542    

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