Second set of ghostscript vulnerabilities.

[ken@…]

After #11230, there are apparently more potential vulnerabilities, from posts to oss-security by Tavis Ormandy:

A small update, one of these commits was to mark all procedures that use
dangerous operators as operators themselves. The idea is that error
handlers will only see the top-level operator and not any sub-operators (I know, this is getting complicated).

I noticed a procedure upstream missed, .loadfontloop. Upstream have double
checked if there were any others, and I did too - we think that is all of
them.

So this commit is necessary as well:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a5a9bf8c6a63

and

Hello, this <https://bugs.chromium.org/p/project-zero/issues/detail?id=1690>
is another (different from CVE-2018-17961) -dSAFER sandbox escape.

[...]
Once you have a reference to forceput, you can do anything you like, see
the exploit for CVE-2018-18073 as an example of abusing forceput to get
arbitrary filesystem access.

The fix is public now, this is the commit to fix it:

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=34cc326eb2c5695833361887fe0b32e8d987741c

I will note that for the previous set of fixes I had to add an intermediate commit to be able to apply the second fix, so this might be similar (obviously, on top of the first set of fixes).

[ken@…]

That first one applies ok, but the second again seems to be meed one or more other changes since the 9.25 release, and there appear to have been 50+ commits, not all of which seem security related. Since there is no public tree I can clone (just a series of all commits at artifex and the option to take any as a snapshot), and AFAICS none of fedora, gentoo, debian have these fixes, for the moment I'm not doing this.

[ken@…]

I spent a long time looking at this a day ago - decided that applying the commit which was giving me trouble was fairly obvious, added all the rest, checked it built, tested - nothing could open any ps or eps file. A DoS is not much of an improvemernt from pwnage.

Sucked my teeth, looked to see what I could glean from the web interface - it is possible to run 'blame' on each file in a commit, but of course that only shows the post-commit state. To look at an earlier version, needed to look at the parent and continue until either one looked possibly-relevant or until it also updated that file and let me look at the previous state to see which commit had updated it. I ended up with 8 commits, in date order (except one appeared to have an incorrect date). Started at the beginning - did not apply (line being changed was incomplete, these are a series of items which get added to). Went back, and I was in business.

Still some offsets (I guess various code has been deleted, I noticed some of that in commits I had ignored). Built, valid ps and eps files all worked. But I lacked the vulnerability. Douglas had something, but gmail would not let him send it.

Today we found a way around that. And the fix works. The new vulnerability is in a PDF. I only tested with evince, but I'm sure other PDF viewers might be affected.

[ken@…]

I could have sworn I closed this. r20641.