-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Arbitrary memory overwrite occurs when loading glyphs and rendering text with a malformed TTF file. #187
Comments
1bsyl
added a commit
that referenced
this issue
Mar 19, 2022
…s and rendering text with a malformed TTF Pitch/size isn't calculated with 64 bits precisions
Thanks for the test-case ! the issue is that the font (indeed malformed, but acceptable) gives big width/height. and the final size wasn't calculated with 64 bits precision (eg badly calculated). (even if glyph goes outside, it gets clipped/truncated. if badly loaded, it get rejected) |
1bsyl
added a commit
that referenced
this issue
Mar 19, 2022
Make sure that 'width + alignment' doesn't overflow, otherwise it could create a SDL_Surface of 'width' but with wrong 'pitch'
CVE-2022-27470 has apparently been assigned to this issue. |
This was referenced May 9, 2022
slouken
pushed a commit
that referenced
this issue
May 9, 2022
This catches up with commits 09a2294 "Fixed bug #187 - Arbitrary memory overwrite occurs when loading glyphs and rendering text with a malformed TTF" and db1b41a "More integer overflow (see bug #187)" in code that was written before those fixes, but merged after them. Fixes: f26fa4c "Add functions to use FreeType ClearType-style LCD rendering (#138)" Signed-off-by: Simon McVittie <smcv@collabora.com>
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Hello, I found a vulnerability in this project.
Summary
Arbitrary memory overwrite occurs when loading glyphs and rendering text with a malformed TTF file.
System Info
Detailed Description
When the function
TTF_RenderText_Solid()
is executed, it internally callsTTF_Size_Internal()
andRender_Line()
. Since the code load and render glyph data after measuring bitmap size, if the measured size has a problem, it causes memory overflow or arbitrary memory write when rendering the data. The bitmap size of glyph affects variablesxstart
andystart
. And they are used to calculate the destination ofBG_SSE()
. Therefore a malformed TTF file that has manipulated glyph data will result in memory corruption.If the rendered string has only characters that mapped malformed glyph data,
ft_failure
occurs when callingFT_Render_Glyph
. But, if the string has a character that mapped normally formed glyph data in front of the mal-mapped character, the normal character is rendered with corrupted size whileFT_Render_Glyph
is normally called. So, the normal character's glyph data is overwritten to arbitrary memory addresses with corruptedxstart
andystart
. The address will be heap or stack.In the below code and attached malformed TTF file, a character "T" has normal glyph data and a character "S" has malformed glyph data. Since The address of the calculated destination with
xstart
andystart
is not a valid memory address, a segmentation fault occurs. debugged data is below.Reproduce
compile the below code and run the program with a malformed TTF file. A malformed TTF file link is here
main.cpp
compile & run
Conclusion
In my thought, the part of the responsibility for this vulnerability partially rests with FreetypeFont. Usually, opening malformed TTF file results in an error code. But in here, it doesn't. I will report this issue to FreetypeFont. However, I think it would be good to add the routine that checks the range of variables
xstart
andystart
before callingRender_Line
.The text was updated successfully, but these errors were encountered: