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:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	abhgupta, apmukher, dbaker, drepper, fche, jakub, jokerman, me, mjw, mjw, sthangav, trankin
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-06 13:21:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1677539, 1679078, 1679079
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

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

Comment 11 errata-xmlrpc 2019-11-05 21:13:50 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

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