TL;DR: Flaw in Postscript language specification opens Ghostscript to variable scope manipulation exploits via dictionary stack manipulation through subroutine name replacement following the weak/late binding of custom subroutines allowing circumvention of all security/ACL
-
-
-
I think I got that right or at least close enough, but damn great find
End of conversation
New conversation -
-
-
I guess the lesson is sandbox, isolate, de-permission and periodically powerwash the systems that render previews or handle untrusted content. It should not be a novel learning any more...
-
It's weird that I hear so much more about bugs in libraries or tools like this than about best practices or considerations for deploying them safely. It would be
to link a quality rundown of strategies for safely deploying software in this use-class off each bug announce
End of conversation
New conversation -
-
-
Nice. 20 years ago I checked whether you could read /etc/passwd from PostScript. I couldn't get it to work - a straightforward read attempt gives an /invalidfileaccess error. I should have tried harder!
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
-
Damn, now I need to see if I can use startjob to set the initial VM state in GS...
End of conversation
New conversation -
-
-
You weren't joking about a non-trivial amount of work to patch the specification flaw... nice find, as always
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Spooky
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
-
He gives the solution ;) Deprecate untrusted Postscript. Consider using it only as a format to get your stuff from your computer to your printer. Of course if you're a professional print shop your life is already malware rich.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.