Bug 1920456 (CVE-2020-14409) - CVE-2020-14409 SDL2: Integer overflow in SDL_BlitCopy in video/SDL_blit_copy.c via a crafted .BMP file
Summary: CVE-2020-14409 SDL2: Integer overflow in SDL_BlitCopy in video/SDL_blit_copy....
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-14409
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1921866 1920457 1921356 1921357 1921358 1921865
Blocks: 1920460
TreeView+ depends on / blocked
 
Reported: 2021-01-26 11:10 UTC by Marian Rehak
Modified: 2022-04-17 21:06 UTC (History)
9 users (show)

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.
Clone Of:
Environment:
Last Closed: 2021-11-02 18:26:54 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.