Bug 1920456 (CVE-2020-14409)

Summary:	CVE-2020-14409 SDL2: Integer overflow in SDL_BlitCopy in video/SDL_blit_copy.c via a crafted .BMP file
Product:	[Other] Security Response	Reporter:	Marian Rehak <mrehak>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	dchen, erik-fedora, igor.raits, klember, maci, manisandro, ppisar, spotrh, wtaymans
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	SDL 2.0.14	Doc Type:	If docs needed, set a value
Doc Text:	A flaw was found in SDL2. An attacker who is able to submit a crafted file to an application depending on SDL2's functionality could trigger an integer overflow and subsequent out-of-bounds write. The highest impact is to data confidentiality and integrity as well as system availability.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-11-02 18:26:54 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:	1920457, 1921356, 1921357, 1921358, 1921865, 1921866
Bug Blocks:	1920460

Description Marian Rehak 2021-01-26 11:10:06 UTC

SDL (Simple DirectMedia Layer) through 2.0.12 has an Integer Overflow (and resultant SDL_memcpy heap corruption) in SDL_BlitCopy in video/SDL_blit_copy.c via a crafted .BMP file.

Reference:

https://bugzilla.libsdl.org/show_bug.cgi?id=5200

Comment 1 Marian Rehak 2021-01-26 11:10:33 UTC

Created SDL tracking bugs for this issue:

Affects: fedora-all [bug 1920457]

Comment 2 Petr Pisar 2021-01-26 12:47:19 UTC

Didn't you mistaken SDL with SDL2?

The linked patch is for SDL2 and it makes sure that calculating int surface->pitch in SDL_CreateRGBSurfaceWithFormat() does not overflow and thus that any subsequent memory allocation and access based on the pitch and surface->width and surface->height are correct.

SDL we have in Fedora and RHEL and upstream has is already hardened: SDL_CreateRGBSurface() makes sure that width and height fits into unsigned 16-bit integer and SDL_CalculatePitch() makes sure that the pitch computation also fits into unsigned 16-bit integer (surface-pitch is Uint16 type there). The multiplication at SDL_malloc(surface->h*surface->pitch) in SDL_CreateRGBSurface() cannot overflow because the argument has size_t type which is not shorter than unsigned 32-bit on any Fedora and RHEL supported platform. Therefore I think SDL is not vulnerable.

Do you have a counter example? Or at least reproducer for the original SDL2 bug?

Comment 3 Todd Cullum 2021-01-27 22:35:11 UTC

Created SDL2 tracking bugs for this issue:

Affects: epel-7 [bug 1921358]
Affects: fedora-all [bug 1921356]


Created mingw-SDL2 tracking bugs for this issue:

Affects: fedora-all [bug 1921357]

Comment 6 Todd Cullum 2021-01-28 18:26:12 UTC

Upstream patch: https://hg.libsdl.org/SDL/rev/3f9b4e92c1d9

Comment 7 Todd Cullum 2021-01-28 18:29:45 UTC

Seems to be quite similar to CVE-2017-2888.

Comment 8 Petr Pisar 2021-01-29 08:30:43 UTC

The upstream patch https://hg.libsdl.org/SDL/rev/3f9b4e92c1d9 for CVE-2020-14409 corrects computing pitch and changes SDL_COMPILE_TIME_ASSERT() macro. But the next commit reverts the SDL_COMPILE_TIME_ASSERT() change as unnecessary. Thus CVE-2020-14409 is only about computing the pitch in SDL2.

The same pitch bug in SDL has already been reported and fixed as CVE-2019-7637.

CVE-2017-2888 fixed related integer overflows when allocating the pixels memory.

Comment 9 Todd Cullum 2021-01-29 19:31:50 UTC

Statement:

SDL as shipped in Red Hat Enterprise Linux 6, 7, and 8 is not affected as the vulnerable code exists in SDL2; SDL is already hardened for this flaw.