Bug 708132 - [RCE] DOCXWRITE TXTWRITE device: Text buffer overflow with long characters
Summary: [RCE] DOCXWRITE TXTWRITE device: Text buffer overflow with long characters
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Security (public) (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-12 03:22 UTC by zhutyra
Modified: 2025-03-20 11:42 UTC (History)
9 users (show)

See Also:
Customer:
Word Size: ---

Attachments
patch (2.23 KB, patch)
2024-11-12 03:22 UTC, zhutyra 		Details | Diff
exploit (3.38 KB, application/postscript)
2024-11-12 03:23 UTC, zhutyra 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description zhutyra 2024-11-12 03:22:50 UTC 
Created attachment 26191 [details]
patch

The "docxwrite" and "txtwrite" devices expect a maximum of 4 code units per character when rendering text, and if a font contains a longer value, it results in a buffer overflow.

I also fixed the length in memcpy when copying predefined glyph values, which is unrelated to this vulnerability.
Comment 1 zhutyra 2024-11-12 03:23:25 UTC 
Created attachment 26192 [details]
exploit

Exploit for x64 Linux
gs -q -sDEVICE=txtwrite -sOutputFile=/dev/null textbuffer.ps
Comment 2 Ken Sharp 2024-11-21 10:14:47 UTC 
I thought it would be better to pass in a buffer length, but that resulted in more changes than I really wanted to do because it involved adding error handling to places that didn't do it.

So in the end I adopted the patch, but I preserved the deleted comment (because it's useful to me) and added another comment explaining the magic number of '4 * sizeof(unsigned short)'

One day we may even get round to rewriting the Unicode handling.
Comment 3 Chris Liddell (chrisl) 2025-03-10 09:54:34 UTC 
CVE-2025-27831