Bug 1706046 (CVE-2005-3590)

Summary:	CVE-2005-3590 glibc: buffer overflow in getgrouplist function leading to corrupted memory
Product:	[Other] Security Response	Reporter:	Marian Rehak <mrehak>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	aoliva, arjun.is, ashankar, codonell, dj, fweimer, glibc-bugzilla, law, mfabian, mnewsome, pfrankli, rth, siddhesh
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	glibc 2.3.5	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-03 20:51:35 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:
Bug Blocks:	1706047

Description Marian Rehak 2019-05-03 12:40:08 UTC

The getgrouplist function in the GNU C library (glibc) before version 2.3.5, when invoked with a zero argument, writes to the passed pointer even if the specified array size is zero, leading to a buffer overflow and potentially allowing attackers to corrupt memory.

Comment 1 Tomas Hoger 2019-05-03 20:48:22 UTC

Upstream bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=661

Upstream commit:

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2e6a02d832158ac81d1ecceff1834455633d58bd

Comment 2 Tomas Hoger 2019-05-03 20:51:35 UTC

This is an ancient bug that never affected any of the currently supported Red Hat Enterprise Linux versions.

Additionally, its impact seems very limited as the problem was triggered by having getgrouplist() called with ngroups argument of 0.  This is unlikely use case.  This argument is likely to be hard-coded in programs, rather than taking a value from an untrusted source.

Comment 3 Tomas Hoger 2019-05-03 21:02:09 UTC

In reply to comment #2:
> Additionally, its impact seems very limited as the problem was triggered by
> having getgrouplist() called with ngroups argument of 0.  This is unlikely
> use case.

To clarify, this would be a valid way to probe how big the size of the groups array should be.  This would, however, trigger out of bounds access during probing, regardless of whether it was malicious or non-malicious use case.  This seems more of a bug than a security issue.