Created attachment 23886 [details] This zip archive includes three POC for GhostScript version 9.55.0 pulled from the package manager on ubuntu, GhostScript 10.0.0 and 10.01.0, compiled from source on Debian Hi, I found an exploitable buffer overflow in the s_xBCPE_process (called by both BCPEncode and TBCPEncode filter), which seems to impact many version of GhostScript interpreter. Within the s_xBCPE_process, it is possible to ends up with the write pointer (q, in the code) greater than the write limit pointer (pw->limit). This can be achieved by trying to write more data than the target source can handle, and passing an escaped character as the last writable character. The issue can be easily seen in debug mode (-Zs), with the following POC: /writtenTo {4 string} def /ourFilter writtenTo /BCPEncode filter def /readsFrom <414141134141> def ourFilter readsFrom writestring ourFilter flushfile After the write, to the filter, the debug statement should print: [s]write process 0x560dc8218ba8(stream_state), nr=6, nw=4, end=0 [s]after write 0x560dc8218ba8, nr=2, nw=4294967295, end=0, status=1 The nw=4294967295 indicates that the pw->limit - pw->ptr operation overflowed. Any subsequent write to the filter will not be bounded. This can be exploited by chaining two filter together, as demonstrated in the attached POC. The out of bound write will overwrite the current stream structure, allowing an attacker to craft handy arbitrary read and arbitrary write primitive or simply hijack a function pointer within the proc structure. With those primitive, it is possible to disable the sandbox by overwriting the path_control_active variable, and execute code on the victim machine. I attached three POC, one for Ubuntu 22.04.2 GhostScript package (which is GhostScript 9.55), one for Debian with GhostScript version 10.0.0 compiled from source, and for Debian for GhostScript version 10.01.0, compiled from source. For any of those POC, the result should look like : ./gs -dSAFER -f debian10.01.0.ps GPL Ghostscript 10.01.0 (2023-03-22) Copyright (C) 2023 Artifex Software, Inc. All rights reserved. This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details. Found leak: 0x000055C5BA2A6D67 Null filter address will be @ 0x55C5BA2DB558 read cursor address -1 should be @ 0x55C5BA2DB5C7 context addr @ 0x000055C5B9FB0BD8 path_control addr @ 0x55C5B9FAE5BA GS<1>uid=1000(debian) gid=1000(debian) groups=1000(debian) [...] As the escaped character in BCPEncode or TBCPEncode can not be written (at least with my POC) you may need to restart to exploit to get a correct ASRL layout. Furthermore, as describe in the POC, you may need to change the offset between the leak we get and the NullFilter created after. For the remediation, I'm no C nor GhostScript expert, but I guess the s_xBCPE_process should check if incrementing twice the write pointer (q) does not result in q > pw->limit. I stay at your disposition for any additional information. Thanks, Hadrien.
Firstly apologies for the slow response, we were literally pushing the 10.01.0 release out the door on Wednesday which involves some administrivia so our attention was temporarily diverted. I've made two commits to address this and potential related issues. The first is 37ed5022cecd584de868933b5b60da2e995b3179 which prevents the overrun. Secondly, in the same vein as we've done in the past with PostScript operators, commit 3635f4c75e54e337a4eebcf6db3eef0e60f9cebf removes a load of non-standard filters. Some of these were used by the old PDF interpreter, a number seem to have been included just for symmetry with a companion Encode/Decode filter, and a few I have no clue why they are there; they are not used. Removing these reduces the attack surface so we should do that. I have not closed the bug! I believe this warrants an out of band release (given the proof of concept), sadly only days after the main release but that's life. I'd like to leave this open and therefore not publicly disclosed, even though technically there is a patch available, until we have a chance to make a release generally available. That won't, unfortunately, be before the weekend. I'll leave the bug assigned to Chris to close when we have a patch release up.
Hi, Thanks for the quick response, I can confirm that removing filters and reducing the attack surface in general is a really good idea. From an administrative point of view (I'm sorry to bother you with this), could this bug be eligible for your bug bounty program, or is this inquiries addressed in a completely different channel ? Thanks, Hadrien
We have been assigned CVE-2023-28879 for this issue.
(In reply to hperri from comment #2) > Hi, > > Thanks for the quick response, I can confirm that removing filters and > reducing the attack surface in general is a really good idea. > > From an administrative point of view (I'm sorry to bother you with this), > could this bug be eligible for your bug bounty program, or is this inquiries > addressed in a completely different channel ? > > Thanks, > Hadrien Hello Hadrien, please write me at the email address associated with my Bugzilla user name about the bounty.
For the attention of the distribution package maintainers CC'ed here: Please roll out this patch to your Ghostscript pagage(s) ASAP, this is relevant to any version of Ghostscript: https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=37ed5022cecd We plan to make this bug public in approximately 7 days.
Hello, Do you know how i can do this for PC (Windows 10) I don't know how to fix it
(In reply to Mosaab from comment #6) > Hello, > > Do you know how i can do this for PC (Windows 10) > > I don't know how to fix it https://artifex.com/news/critical-security-vulnerability-fixed-in-ghostscript