World's favourite open-source PDF interpreter needs patching (again) Google Project Zero bug-hunter Tavis Ormandy took a "random look at the new release" of Ghostscript, and found a partly addressed vulnerability present in all versions up to 9.26. Ormandy made his latest discovery on 11 December, while reviewing a bug fix sent to him by devs at Artifex, which maintain Ghostscript and came up …
Look at the specifications for PDF. It's unholy. A tangled mass of extensions-to-extensions-to-extensions, built upon a foundation of encodings that are seen no-where else and technologies that have been obsolete since the 90s. The only place I've seen where single and double angle brackets are both used as delimiters, and can appear consecutively.
It really isn't an extension of PostScript, more a restriction. PostScript is a Turing-complete Forth-like language. PDF supports a tokenised subset of that, omitting, for example, fairly fundamental things like loops and also programmer-defined functions (which seems to be part of the vulnerability in this case?)
Sorry but no. PDF is not an extension of PostScript. PostScript is a programming language, PDF isn't. PDF doesn't mandate error handling in the way that PostScript does, so the attack (which depends on error handlers) simply can't work, at all, on a PDF consumer which isn't implemented in PostScript (Ghostscript's PDF interpreter is written in PostScript, but that doesn't make it vulnerable to this attack either).
PDF is not 'PostScript at the bottom' all they share is some part of their imaging models.
It's worse than that. PDF was invented specifically to sidestep the complexity of full PostScript documents. (Because apparently people didn't need a language that could be used to make your printer compute fractals)
Twenty five years later, how do you think that "simpler than PostScript" idea is working out?
PDF incorporates postscript, but PDF is not postscript.
PDF is, at core, a container format. It contains objects. Some of these objects are postscript documents (Or rather, a simplified subset of postscript) which define the drawing of pages. Other objects are resources that this postscript can call upon, such as fonts or images. There are also objects involved in various extensions such as edit protection, version management or metadata.
Prior to PDF, postscript was rather cumbersome to use: It depended upon your document renderer (be it software, or firmware in your printer) having all of the required fonts installed, and being able to render images. This sort of worked, but if might mean that your postscript printed slightly differently on different printers because they used different fonts. PDF was intended to solve this by taking that postscript and bundling it into a file with all the fonts required, and limiting which features could be used to ensure compatibility. It actually worked very well, which is why it became so popular. It also added navigation data and dependency rules that make it possible to view any page at random - you don't run into problems rendering page 78 because it refers back to a template from page 60 which incorporates a logo from page 112, another curse of postscript.
Inside of PDF though, it's a horror. A horror which people are shielded from by libraries: Programmers need only call upon libpdf to extract those resources as needed, and need not look into the abyss.
How bad is it? Consider this: PDF supports single-byte ASCII encoding, and two-byte UTF-16 encoding, for strings. These may be freely mixed within one string, using escape codes to switch between them. This weird method is used because PDF predates the introduction of UTF-8. It means that you cannot use any of the common string-handling functions when working on raw PDF objects.
I was all ready to blame Adobe (why are their formats also so complex and insecure), but yeah, at the end is says:
[Ormandy]'s still wary of the whole thing, writing that "untrusted postscript needs to be deprecated ASAP"
Still, if someone said "PDF" is insecure, no one would bat an eye. Executable code, web hooks, WTH does Adobe think PDFs are for?
Untrusted PS. A different thing. Getting rid of PS is alike getting rid of font files and javascript...
Anyway, anything able to run untrusted code on your system is a big risk. Still Tavis master aims to block Chrome add-ons that exist exactly to block untrusted code...
While not a fix, be a dick. Accept it, but never return it. I used to accept pdf, but returned it as html. This was years ago too, before javascript had proper uint support or bpg (although epub should seriously be considered at some point).
PS in general is shit, I never understood why people at the time just didn't use Perl, what made PS so great to give it its own decoder and memory space?
Anyways, if you don't give people a reason to move on, why would they?
Yeah. Even PDF itself only came into existence to get around a sharp memory-constraint problem in the first laserprinter.
See this very prestigious e-journal's own take on it:
https://www.theregister.co.uk/2018/06/21/how_a_tax_form_kludge_gave_us_25_years_of_pdf/
[Demo]The page took 2 minutes 45 seconds to print. Jobs was horrified at how slow that was.
Looking over his lines of PostScript later, Warnock tried a different tack. As he recounted to digital prepress newsletter The Seybold Report in 2001: "You can redefine the operators to have different semantics than the original operators. So I took all of the basic graphics commands in my original program, reprogrammed just a capture of their parameters and wrote those parameters out to a file." This effectively "flattened" the file out.
His new version of the IRS tax form printed on the LaserWriter in 22 seconds.
Untrusted, true, fair point, but that's the vast majority of real-world PostScript. Unless you hand-crafted the code yourself then you shouldn't trust it. If that's all you do, then none of the recent security bulletins affect you (congrats, you win!).
Most people, however, just use ImageMagick etc, on PostScript programs they picked up from some random place and don't even realise they are running program code.
Forgive me, just consider that this comment is by somebody who has been out of this particular room for 20 years. And it is!
Deja Vu produced documents that were more compact than PDFs and, to my eye, looked just as good. HTML could have been written to properly format documents to a fixed page size, but the authors of HTML expressly rejected that concept. Years later, they retrofitted HTML to handle some of those concepts, but the results, at least at the time, didn't impress. From about 1988, either Ventura Publisher or Pagemaker could be used to make good-looking (eye of the beholder, naturally) documents.
I set web browsers to download PDF files rather than display them. My preferred free reader is Sumatra. But I find that when browsers update themselves, they tend to turn on internal rendering of PDF files, even when you've expressly set it off. It's a bit like Vivaldi, after it has updated, has changed my search engine from <search engine I wanted/> to Ecosia.
They're just documents, they shouldn't have vulnerabilities!</rant>
So is this problem just another symptom of jumping on the mercantile bandwagon, rather than following Best Practices? And the fun question: has anybody used Postscript as a general-purpose programming language? To keep track of inventory or something not immediately document related?
Not only that, it is used on Windows, not just *nix systems. Very handy too till I abandoned Windows.
Via Ghostview, which also reads PDFs.
Yes a PDF is really just a wrapper, so the text can be really a TIFF or actually text and postscript. Or both (scanned image and OCR text which is rubbish but aids searching).
Oh, and PDFs are evil to share actual text except for proofing for paper printing, unless your screen can do the entire page at 150dpi or better. HTML, mobi and ePub are all preferable to share documents to be read on an electronic screen where you don't care about the layout in a PRINTED book,magazine or paper sheet.
After looking at the TLDR article (linked to from this one) I can see how a stack overflow was used to read the password file in 'etc' (if I type the path I get prompted with a captcha). A proof of concept exists, then. Yeah, not good.
But _I_ don't want to see Ghostscript go away any time soon, so _I_ am calling for it *NOT* to be 'dumped'! It's too useful. Just fix it.
Which one exactly are you suggesting people use that's preferable?
e.g. the gnu fork doesn't seem to have changed since 2014, so I would presume is exploitable using the majority of the last 5 years of bugs found: http://git.savannah.gnu.org/cgit/ghostscript.git/commit/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
