Hacker News Reader

Comment by godmodus | Hacker News Reader

Post script is Turing complete. So this is not a long shot at all, in fact since most people consider documents safe, it's a very exploitable attack vector.

Pdfs also allow arbitrary code execution, which is not a new result.

Here's an older hackernews discussion about the subject: https://news.ycombinator.com/item?id=4910113

View on HN

> Post script is Turing complete.

That's irrelevant. Turing machines are pretty benign. They can't read or write to your files. The worst they could do is to run forever.

The problem with PostScript is that it allows to much OS interaction, such as file IO. But that has nothing to do with Turing completeness.

The problem with Turing complete implementations is that it is impossible to decide what the code is going to do without running it.

It's not a problem. If there are no commands for file IO, then there can be no file IO. The only thing you can not decide in the general case is if there are file IO commands if they will get executed or not. But even that is no problem, as you can just block/not implement the file IO commands.

But Turing Completeness! ;)

I see your point in the second argument. That said, a Turing complete language, with out os-level checks, is not. For a language thought up to print and display things, it's hard to argue that postscript is as harmless as HTML, for example.

There's one thing I don't understand: Given documents like pdf allow for turing-complete scripting, but is not intended for extensive computation, why not simply sandbox its execution? I'm thinking about something like a virtual machine simulating stack and stack pointers, and just providing whatever is safe and necessary. It doesn't appear extremely hard to do for something like PostScript - of course, performance might be bad, but that's probably not too relevant for documents anyway.

The "PDF language" itself is not that complex per se and ofc. executes in a VM. PDF also allows to embed various stuff, including Flash and JavaScript, which both execute in a VM as well.

No PDF reader was supposed to just execute x86 instructions from a PDF file (wouldn't be very Portable, would it?), although many PDF readers had enough security issues that it's an arguable viewpoint.

Reason gives way to production deadlines and some measures were implemented at viewer/av/printer levels. That said, it comes down to budgets, effort and deadlines. As to why doesn't one of us do it.. We I had a friend who wrote a pdf parser and he tells of the nightmare still. Pdfs apparently vary in their implementation, and there's no sure fire way to parse them all in the same.e way. Differences are usually small things, but it's enough to cause a non trivial amount of issues and cases to account for. The specification is also apparently a nightmare. Least to say, he would never touch pdfs again.

Pdf is a curious case, sort of like flash, but has no real html5 variant, if that makes sense.

That's definitely possible (and advisable) in GhostScript - the article itself touches on this in the end, when it mentions you need to use -dNOSAFER for the example to work in ps2pdf.

https://ghostscript.com/doc/9.20/Use.htm#Options

The SAFER and NOSAFER options are described here, and SAFER is essentially a sandbox. So, the problem described isn't so much a problem with PostScript, as a problem with anybody that writes an app that fails to invoke their PostScript interpreter appropriately. Apparently some unnamed web application had this problem, but ps2pdf does not.

What you've described sounds exactly like a PostScript interpreter! You can easily write a metacircular PostScript interpreter in PostScript!

http://www.donhopkins.com/home/psiber/cyber/ps.ps.txt

And here is a PostScript quine:

    {{[ exch /dup load /exec load ] cvx} dup exec}

If you wanted to produce "safe" PostScript file for printing, that used a standard header file and didn't require a Turing complete printer with loops, conditionals, functions, etc, you could write a partial evaluator for PostScript that projects it against the stencil-paint imaging model, optimizes the graphics, and prints out another "safe" PostScript program using a standard header, with all the loops unrolled and conditionals evaluated and functions called and graphics in the same coordinate system. That would enable you to capture anything you draw on the screen, independent of the PostScript algorithmic procedures and classes and libraries and application required to draw it.

http://www.donhopkins.com/home/psiber/cyber/distill.ps.txt

Glenn Reid, who also wrote books on PostScript like Thinking in PostScript, pioneered that idea in his "PostScript Language Distillery", which is the idea that grew into PDF.

http://donhopkins.com/home/archive/postscript/newerstill.ps....

Here's a post I wrote about printing and debugging PostScript in the NeWS window system:

https://news.ycombinator.com/item?id=11479364

And here's a paper I wrote in 1989 that describes the NeWS version of Distillery and the metacircular PostScript evaluator. At Sun we later built a PostScript distillery into the NeWS toolkit to support printing NeWS applications as PostScript:

http://www.donhopkins.com/drupal/node/97

The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines - October 1989

[...]

Printing Distilled PostScript

The data structure displays (including those of the Pseudo Scientific Visualizer, described below) can be printed on a PostScript printer by capturing the drawing commands in a file.

Glenn Reid's "Distillery" program is a PostScript optimizer, that executes a page description, and (in most cases) produces another smaller, more efficient PostScript program, that prints the same image. [Reid, The Distillery] The trick is to redefine the path consuming operators, like fill, stroke, and show, so they write out the path in device space, and incremental changes to the graphics state. Even though the program that computes the display may be quite complicated, the distilled graphical output is very simple and low level, with all the loops unrolled.

The NeWS distillery uses the same basic technique as Glenn Reid's Distillery, but it is much simpler, does not optimize as much, and is not as complete.

[...]

The Metacircular Postscript Interpreter

A program that interprets the language it is written in is said to be "metacircular". [Abelson, Structure and Interpretation of Computer Programs] Since PostScript, like Scheme, is a simple yet powerful language, with procedures as first class data structures, implementing "ps.ps", a metacircular PostScript interpreter, turned out to be straightforward (or drawrofthgiarts, with respect to the syntax). A metacircular PostScript interpreter should be compatible with the "exec" operator (modulo bugs and limitations). Some of the key ideas came from Crispin Goswell's PostScript implementation. [Goswell, An Implementation of PostScript]

The metacircular interpreter can be used as a debugging tool, to trace and single step through the execution of PostScript instructions. It calls a trace function before each instruction, that you can redefine to trace the execution in any way. One useful trace function animates the graphical stack on the PSIBER Space Deck step by step.

The meta-execution stack is a PostScript array, into which the metacircular interpreter pushes continuations for control structures. (forall, loop, stopped, etc...) A continuation is represented as a dictionary in which the state needed by the control structure is stored (plus some other information to help with debugging).

It is written in such a way that it can interpret itself: It has its own meta-execution stack to store the program's state, and it stashes its own state on the execution stack of the interpreter that's interpreting it, so the meta-interpreter's state does not get in the way of the program it's interpreting.

It is possible to experiment with modifications and extensions to PostScript, by revectoring functions and operators, and modifying the metacircular interpreter.

The metacircular interpreter can serve as a basis for PostScript algorithm animation. One very simple animation is a two dimensional plot of the operand stack depth (x), against the execution stack depth (y), over time.

[...]

Woops, the right link to the NeWS distillery is:

http://www.donhopkins.com/home/archive/psiber/cyber/distill....

And here is The NeWS Toolkit version of capture.ps that captures NeWS application window drawings as PostScript:

http://www.donhopkins.com/home/code/capture.ps.txt

But Glenn Reid's original tour-de-force PostScript Distillery is still the gold standard, that does the most optimization and works with more PostScript documents, and led the way to PDF. (Adobe's Acrobat Distiller is actually built into a real PostScript interpreter, not written in PostScript like Glenn's Distillery, but he proved the possibility and usefulness of the concept, and the power and flexibility of PostScript, long before PDF was a thing.) It's a great read if you want to learn a lot about the inner workings of PostScript:

http://donhopkins.com/home/archive/postscript/newerstill.ps....

No one is assuming documents are safe.

Presentation and functional scripting in documents is often blocked or heavily restricted/monitored this includes PDF most mail scanners know very well to block or filter PDF files based on postscript.

Every now and then you'll see some av or email provider like gmail block PDF files in masses often ones that were generated by a very specific program or process and very often because their internal post script was iffy.

Reply on news.ycombinator.com