CVE-2023-43115: Ghostscript IJS device bypasses SAFER, allowing path-traversal arbitrary file write and RCE

Ghostscript ghostpdl-10.01.2's IJS device (devices/gdevijs.c) lets PostScript programs running under -dSAFER write output to arbitrary paths and, in some configurations, execute arbitrary commands. Two missing checks in gsijs_open are responsible: (1) the user-controlled IjsServer string is passed straight to ijs_invoke_server, which in ijs/ijs_exec_unix.c forks and runs execvp("sh", "-c", server_cmd, NULL), and (2) the output filename ijsdev->fname is forwarded to the spawned IJS subprocess via ijs_client_set_param(ctx, 0, "OutputFile", fname, ...) so the child — not Ghostscript — opens the file. SAFER only validates files Ghostscript itself opens, so traversed paths like ../../../../tmp/pwned are written without complaint. The lone dev->LockSafetyParams check in gsijs_read_string only blocks re-assigning IjsServer after lock; it does not validate the path or the output filename. Followed the call-chain hint gs_main_run_start -> gsijs_open -> gs_lib_ctx_stash_sanitized_arg. (1) grep gsijs_open => devices/gdevijs.c:767. (2) Read gsijs_open: at line 822 it calls ijs_invoke_server(ijsdev->IjsServer) with no gp_validate_path and at lines 855–856 forwards ijsdev->fname as OutputFile. (3) grep ijs_invoke_server => ijs/ijs_client.c:42 calls ijs_exec_server. (4) Read ijs/ijs_exec_unix.c: shows execvp("sh", "-c", server_cmd, NULL) confirming shell-context execution. (5) Read gsijs_read_string at gdevijs.c:1224 — only checks safety && differs to block changing IjsServer post-lock; performs no path validation. (6) grep gp_validate_path inside gdevijs.c => no matches, confirming SAFER's path validator is never invoked here. The combination is the classic "subprocess does the I/O, parent's sandbox is bypassed" pattern. Add gp_validate_path(dev->memory, ijsdev->IjsServer, "x") and (when not using OutputFD) gp_validate_path(dev->memory, ijsdev->fname, "w") at the top of gsijs_open BEFORE ijs_invoke_server is called. This forces both the helper-binary path and the output filename through SAFER's PermittedPaths list. Optionally, replace the sh -c exec in ijs_exec_unix.c with a direct execvp(server_cmd, ...) (or execv with argv pre-tokenized) so that even an authorized IjsServer can no longer be a shell snippet. Verified by source inspection: (a) devices/gdevijs.c does not call gp_validate_path; (b) ijs/ijs_exec_unix.c lines 73–78 confirm sh -c shell wrapping; (c) gsijs_read_string only enforces LockSafetyParams equality, not path safety; (d) The OutputFile parameter (line 855) is sent to a child process, so SAFER's "Ghostscript opens the file" guarantee never fires. runtime