In article <
[email protected]>,
[email protected] says...
On Monday, September 9, 2019 at 10:17:20 PM UTC-5, luser droog wrote:
On Monday, September 9, 2019 at 5:02:42 PM UTC-5, luser droog wrote:
https://gist.github.com/rebirthwyw/d401fc375620d4497cc993045736a168
I'm not sure I entirely get it. Are the doubled brackets intended to "deactivate" the code so it doesn't actually do anything unless modified? That's the only thing I can think of.
It appears this can only be used when the pdf device is active.
So if you process to ps2 first and then run the "clean" ps output
to make a pdf, that would completely invalidate the entire approach
here. If this technique is used, there are limits to what can be done.
So the permissions of the 'gs' binary are important.
YMMV IANASA
Screening should be easy. Bona fide documents should never be poking
into /.pdf* . Although now thas I say that....sigh
It was fixed some time back, which is why its now public.
Probably this commit :
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h= 885444fcbe10dc42787ecb76686c8ee4dd33bf33
or this one:
http://git.ghostscript.com/? p=ghostpdl.git;a=commit;h=cd1b1cacadac2479e291efe611979bdc1b3bdb19
All the main package repositories should by now have fixed binaries
available, and the forthcoming 9.28 release won't suffer from the
problem, even if you do manage to get a definition of .forceput, since
the file permissions are now handled outside the PostScript environment.
This entire class of exploit simply won't work any more.
That said, we don't want people playing with non-standard PostScript
functions, so one of the things we've been doing is removing them, or
making them inaccessible, which is why those commits above were done,
even though the exploit no longer works.
As to how it works, its complicated. Its basically abusing the
PostScript error handler, then provoking an error in a specific
function, part of the PDF interpreter code. When that happens a
PostScript procedure is left on the stack and that procedure contains an operator. By knowing how the procedure is constructed the code carefully
picks that operator out, and then assigns it to its original name
(/.forecput). It then uses that to write to a read-only dictionary,
overwriting the file access permissions.
The remainder of the program is just there to make it look pretty, it
does get in the way of fixing these sorts of problems, because it
obscures the main point. The reason its done like that is because the
original author who understood the code write it that way, the several
versions knocking around using other operators were uncovered by people
who may not have really understood the PostScript, they just searched
through the Ghostscritp support code looking for .forceput and then
inserting that function in place of the original one.
Apologies for the slow response, I've been on vacation.
Ken
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)