Bug 1790048 (CVE-2019-5188)

Summary:	CVE-2019-5188 e2fsprogs: Out-of-bounds write in e2fsck/rehash.c
Product:	[Other] Security Response	Reporter:	Pedro Sampaio <psampaio>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	esandeen, josef, kasal, kzak, lczerner, oliver, sct
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	e2fsprogs 1.45.5	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-09-29 21:59:30 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:	1783777, 1790049, 1792193, 1797731, 1797732
Bug Blocks:	1790051

Description Pedro Sampaio 2020-01-11 14:47:02 UTC

A code execution vulnerability exists in the directory rehashing functionality of E2fsprogs e2fsck 1.45.4. A specially crafted ext4 directory can cause an out-of-bounds write on the stack, resulting in code execution. An attacker can corrupt a partition to trigger this vulnerability.

References:

https://talosintelligence.com/vulnerability_reports/TALOS-2019-0973

Upstream patches:

https://github.com/tytso/e2fsprogs/commit/8dd73c149f418238f19791f9d666089ef9734dff
https://github.com/tytso/e2fsprogs/commit/71ba13755337e19c9a826dfc874562a36e1b24d3

Comment 1 Pedro Sampaio 2020-01-11 14:47:20 UTC

Created e2fsprogs tracking bugs for this issue:

Affects: fedora-all [bug 1790049]

Comment 3 Marco Benatto 2020-02-03 21:43:10 UTC

There's an issue with fsck application contained on e2fsck package. The fsck application runs the filesystem checking and repair for ext3 and ext4 filesystems. During the Pass 3 it tries to hash all filenames contained into a given directory as one step, if a rash collision is detected is temporarily renames the file to solve the collision. During this step it relies on direntry metainformation to read from disk the file's name lenght, however due to lack of validation if the metadata is still corrupted it eventually may read the length as zero from disk. As this value is further used in mutate_name() as a part of a calculation to generate an index for a in-memory buffer, the invalid value may trigger an out-of-bounds read which may lead to data corruption and eventually code execution.

Comment 4 Marco Benatto 2020-02-03 21:45:55 UTC

It's important to notice that at Pass, 3a where the issue happens, all directory entries should already had any entry related corruption already. However this a chance the user declined to fix a given entry which may end up leaving the crafted corrupted entry available to trigger the attack.

Comment 5 errata-xmlrpc 2020-09-29 20:34:10 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2020:4011 https://access.redhat.com/errata/RHSA-2020:4011

Comment 6 Product Security DevOps Team 2020-09-29 21:59:30 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-5188