Bug 699718

Summary: .trysetparams stopped proc can itself stop, leaving page device in insecure state
Product: Ghostscript Reporter: Tavis Ormandy <taviso>
Component: Security (public)Assignee: Chris Liddell (chrisl) <chris.liddell>
Status: RESOLVED FIXED QA Contact: gs-security
Severity: critical    
Priority: P1 CC: scorneli
Version: unspecified   
Hardware: PC   
OS: Windows NT   
See Also: https://bugs.ghostscript.com/show_bug.cgi?id=699654
Customer: Word Size: ---

Description Tavis Ormandy 2018-09-05 13:25:04 UTC
The fix for bug 699714 added this code:


The error handler reinstalls /.LockSafetyParams if anything goes wrong.

I mentioned on IRC that I'm not sure if that stopped proc could itself stop (perhaps from stackoverflow). This bug is just a note to investigate if that's possible, I'll follow up if I can get a repro working or if I'm certain that's not the case.

taviso> Hey, regarding the .trysetparams fix, is it possible the stopped proc could ever fail from /stackoverflow or something before it completes?
taviso> like, you get the operand stack really close to being full, get that stopped proc called and handle /stackoverflow in the errordict...etc, etc
Comment 1 Tavis Ormandy 2018-09-05 17:47:05 UTC
I got it to work, this still reproduces in HEAD (gs -dSAFER -sDEVICE=ppmraw):

currentpagedevice /PageSize get 0 (foobar) put

% fill up the stack with junk
0 1 300360 {} for

{ grestore } stopped clear

(ppmraw) selectdevice

mark /OutputFile (%pipe%id) currentdevice putdeviceprops

Adjusting priority to Critical
Comment 2 Chris Liddell (chrisl) 2018-09-06 09:22:38 UTC
Hmm, I must admit, I though we no longer enforced a hard limit on the stack size - I thought it was only limited by memory...
Comment 3 Chris Liddell (chrisl) 2018-09-07 17:17:07 UTC
I've pushed changes to harden the fix against stack overflows: