Detailing the Security Risks In PDF Standard

crabel writes with this quote from the H Online: "At the 27th Chaos Communication Congress in Berlin security researcher Julia Wolf pointed out numerous, previously hardly known security problems in connection with Adobe's PDF standard. For instance, a PDF can reportedly contain a database scanner that becomes active and scans a network when the document is printed on a network printer. Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers — or even depending on a computer's language settings."

Comments

Abomination

[panaceaa]

"Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers -- or even depending on a computer's language settings."

Amazing -- totally unbelievable!! This should be wholly forbidden. Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you? Text files don't let you do these things! Adobe is clearly going too far.

Re:Abomination

[DamonHD]

i18n is the work of the [devil|diablo|Teufel], clearly.

Rgds

Damon

Re:Abomination

[Anonymous Coward]

Excuse me, but a document format used for storing printed documents on a system should represent the document as if it was printed when viewed again, _not_ suddenly switch the language or layout or whatever.

If it were to display _different content_, as alleged, that would disqualify it from being able to be used for archival of government documents.

Re:Abomination

[QuoteMstr]

It's not that internationalization is the work of the devil, but rather that it should happen at a higher level than an individual PDF. Allowing different content to be displayed in different language environments raises serious questions about document integrity: imagine a international contract PDF that displayed one payment for German users and another for French ones.

PDF-the-document-format is a good thing in that it allows perfect reproduction of a printed document anywhere. PDF-the-generic-container, on the other hand, is both frightening and of dubious utility, but I can see why Adobe might have a business case for trying to drive this approach anyway. This is why we can't have nice things.

Re:Abomination

[Xugumad]

> Excuse me, but a document format used for storing printed documents on a system should represent the document as if it was printed when viewed again, _not_ suddenly switch the language or layout or whatever.

It sounds like what you want is PDF/A ( http://en.wikipedia.org/wiki/PDF/A ), which restricts the PDF to a simple non-scripted document. The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format. DjVu ( http://djvu.org/ ) I believe would also be a good fit.

For example, we're looking at taking in student essays in PDF, attaching a form to the front that marks can be entered into, and the whole document returned to the submission system that then pulls the mark out (as opposed to having to track the mark independently of the material it applies to). I've seen presentations run from a PDF before. It would be a pity to lose these possibilities.

Re:Abomination

[burne]

PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form).

PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs. The problem with that has always been that one would have to know on what make and model printer it would run. But, thanks to Adobe, most people will run their PostScript in a 'virtual' printer inside an Adbode-product, and that makes usefull programming in PostScript a real possibility.

I'd say: Happing programming, it isn't that hard.

Re:Abomination

[jgrahn]

PDF is in essence a PostScript-document (with restrictions of the use of external fonts and in a compressed form).

PostScript is a complete programming-language which implies that one could write PostScript that would react to the environment in which it runs.

A real programming language cannot "react to the environment" unless it has the needed I/O facilities. It seems to me that PostScript (as implemented by ghostscript) has been locked down more and more in this area.

PDF in Adobe's hands on the other hand has acquired more and more dynamic features *not* found in Postscript.

Re:Abomination

[Anonymous Coward]

So this higher level is going to have fully automated language translation to guarantee the precise meaning of the contract is the same in every language? I think anyone expecting a computer solution to that with current technology is going to be disappointed. If I send 20 text files, one in English, one in French, one in German etc. believe it or not I can still put different stuff in each.

The real problem I suspect here is that the reporting of what was said is not reflecting the actual problems perceived just listing some of the mechanism which have been/can be exploited. e.g. Saying that javascript can read and edit pdf documents, erm well javascript can read and edit html, graphics files etc. etc. So a computer language can read and maniupate the contents of computer files who would have thought.

Similarly the multi-language/OS stuff maybe a security issue if I taylor different "payloads" meaning my document appears fine where I can't exploit it and appears fine to me as the author but is evil elsewhere. People trust me, so me saying the document opens fine and is benign may help spread something. If the article reported more detail perhaps the issues at stake would be clearer.

Re:Abomination

[WWWWolf]

"Wolf said that the document format is also full of other surprises. For example, it is reportedly possible to write PDFs which display different content in different operating systems, browsers or PDF readers -- or even depending on a computer's language settings."

Amazing -- totally unbelievable!! This should be wholly forbidden. Who would want to read documentation that knew what system you were running, or what language you could read, and tailored the display to make it more relevant to you? Text files don't let you do these things! Adobe is clearly going too far.

Look, the security problem isn't that the features exist. The security problem is that people are just plain ordinary mortals, and plain ordinary mortals screw things up. Every new option adds another route to failure.

Apple doesn't like to ship too huge manuals. My sister wanted a nice printed GarageBand manual. She sent the PDF manual to my father, who opened it on a computer with an older Windows version of Acrobat Reader that didn't know damn about the language switch thingy. So he ended up getting boundlessly confused when the PDF actually appeared to have zillions of pages in dozens of languages, while the PDF only appeared to have Finnish version when viewed on OS X.

A careless act of "just open the file and press the print button and go have a coffee" could have ended up wasting a lot of paper, because of a nice big fat feature mismatch problem. In Adobe's own damn software. Granted, not an earth-shattering problem, but inexplicable and unexpected behaviour nevertheless. There would have been a lot less puzzled questions if only Apple had shipped separate PDFs for different languages.

Hmm, I wonder how many people have ended up screaming and shouting when someone else printed the wrong language version for them, because they didn't even notice the document has different language versions in them and the computers were set to different locales. I'm sure there's lots of confusion about when a document that's sold as the ultimate solution to print the document the exact same way in every platform on every computer doesn't work as expected.

Re:Abomination

[Anonymous Coward]

A recording of the presentation will soon appear here and should answer your request for more details.

Re:Abomination

[TheRaven64]

Not exactly. A subset of PDF is almost identical to a subset of PostScript. A PDF file is a dictionary of objects. These can be in a variety of formats, including binary data which can contain images and so on. One of the formats is drawing commands. These can be written in an extended subset of PostScript, with the flow control primitives removed and a few other commands added. You can convert PostScript to PDF by executing the PostScript program and recording the trace through it (basically, unwind all of the loops, pick one branch in all of the conditionals) - the subset that controls drawing is the same in both.

Re:Abomination

[butlerm]

The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format.

That was its sole intent when it was created, and for several years afterward. Rudimentary javascript support wasn't added until 1996. Audio / video embedding is a much more recent addition (2008 or so). See here.

Re:Abomination

[Jah-Wren Ryel]

For example, we're looking at taking in student essays in PDF, attaching a form to the front that marks can be entered into, and the whole document returned to the submission system that then pulls the mark out (as opposed to having to track the mark independently of the material it applies to).

That's ripe for a hack. A smart kid will come up with code he can add to his PDF at submission that will identify the form and change the mark to a higher grade and then, if he's really clever, rewrite the PDF to delete any sign of the grade changing code.

Re:Abomination

[bcrowell]

> Excuse me, but a document format used for storing printed documents on a system should represent the document as if it was printed when viewed again, _not_ suddenly switch the language or layout or whatever.

It sounds like what you want is PDF/A ( http://en.wikipedia.org/wiki/PDF/A ), which restricts the PDF to a simple non-scripted document. The fact that PDF is almost solely used to produce printed documents doesn't mean that's the intent of the format. DjVu ( http://djvu.org/ ) I believe would also be a good fit.

For example, we're looking at taking in student essays in PDF, attaching a form to the front that marks can be entered into, and the whole document returned to the submission system that then pulls the mark out (as opposed to having to track the mark independently of the material it applies to). I've seen presentations run from a PDF before. It would be a pity to lose these possibilities.

Everything in your post makes sense, but now let's get back to the security issues.

If the security issue is that unsophisticated users get their computers owned because they click on a PDF link, then PDF/A isn't a solution. It isn't a solution for at least three reasons: (1) PDF/A is not an appropriate format for general use on the web, because it requires embedding all fonts. This makes the PDF much bigger, and that means the user's experience is slower. People already get bent out of shape about how long it takes for a PDF to load. They don't want a solution that makes it worse. (2) Advocating that people distribute their documents in PDF/A doesn't help, because bad guys will not follow that advice. (3) Telling users to restrict themselves to software that only accepts PDF/A will not work, because virtually no PDF's they encounter on the web are in PDF/A.

In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."

The cases where I don't know of any good, general solution are cases like the one you're describing, where you want to put students' grades on their papers. The problem here is that you need a feature that goes beyond simply printing and viewing a document. Presumably you've thought about the security issues, and you have a PDF application that has the particular feature you want without exposing you to security issues. The trouble here is that the message now becomes much too complex for the average web user. It's easy to tell them "Use Foxit," and then their problem is solved. But what if they say, "I need features x, y, and z that aren't in Foxit, and I need JavaScript enabled, but I don't want to spend several hours researching how to do this without a security risk?" The only answer I have for such a person is, "Don't do that, because Adobe is clueless about security."

One particularly ugly issue is that if you're in the print advertising or publishing business, you really can't get away with not testing your PDFs in Adobe Reader, but AR is poorly engineered and a security risk. The best you can do is to disable JavaScript.

Re:Abomination

[jklovanc]

One of the big differences between html and PDF is data storage. When using a pdf form someone opens the form inputs the data and that data is saved inside that form; everything is in one place. Html requires three separate pieces; The form to enter the information, the scripts to save the information and the data store (database or file system) to save the data. PDFs are much simpler for handling small quantities of forms.

Re:Abomination

[butlerm]

A subset of PDF is almost identical to a subset of PostScript.

One should say rather that a subset of Postscript, when executed/interpreted produces output that is equivalent to a subset of PDF. PDF isn't based around an interpreter. Javascript/Flash appendages aside, a PDF document won't overflow the stack, does not have infinite loops, won't crash your photo-typesetter or take hours to run, because it is not a scripting language, but rather a vector oriented graphics format.

If Adobe did it over again, it is unlikely that Postscript would have been developed at all. Instead of Postscript printers, we would have had printers that accepted a subset of PDF. It would have solved a lot of problems. At this point Postscript is a historical artifact. PDF/X is its much superior replacement.

Re:Abomination

[ColdWetDog]

No, the OP's father's problem is that he tried to print an Apple document on a Windows computer. This is NOT to be countenanced and, in point of fact, is just this side of Total Blasphemy. It's a good thing he stopped when he did -he's lucky he didn't open a portal to Hell in the process.

Re:Abomination

[camperslo]

What a great feature!

Everyone will get invited to the our next office party, but the Windows users will read that they are to come in clown costumes.

Re:Abomination

[BitterOak]

What a great feature!

Everyone will get invited to the our next office party, but the Windows users will read that they are to come in clown costumes.

It's hard to know whether this should be modded Funny or Insightful, because it's both. And that is precisely what makes these PDF "features" so disturbing.

Re:Abomination

[metrix007]

In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."

Just to point out that on Windows, it is actually more secure to use reader x. The sandbox and exploit mitigation techniques are much better than the negligible gain in security by obscurity in using foxit or sumatra.

Re:Abomination

[bcrowell]

In typical case where the user simply wants to view or print a document, there is an incredibly simple solution. Tell the user to switch to something other than Adobe Reader, e.g., Foxit on Windows, Preview on MacOS X, or Evince on Linux. (For Windows users who get annoyed by how long it takes to open a PDF in a web browser, this has the added selling point of fixing that problem.) For users who can't switch (either because they need features of AR or are in a corporate environment where they can't install software), the next best option is disable JavaScript: go to Edit, Preferences, JavaScript, and uncheck "Enable Acrobat JavaScript."

Just to point out that on Windows, it is actually more secure to use reader x. The sandbox and exploit mitigation techniques are much better than the negligible gain in security by obscurity in using foxit or sumatra.

It took me a while to figure out what you meant. Foxit didn't used to support javascript at all, and that meant that its added security was more than just security through obscurity. It was actually more secure, because all the exploits for AR were based on javascript, which foxit didn't implement. I hadn't realized that foxit later added javascript support. At this point it looks like foxit is roughly equivalent to AR in terms of security: both have js turned on by default, and both allow you to turn it off. ( http://blog.didierstevens.com/2009/05/06/a-very-brief-history-of-foxit-reader-and-javascript/ ) The only possible difference would be whether Adobe or Foxit is more competent in implementing js securely, and that's going to be relatively hard to know, since both are closed source.

Agreed. This is an Adobe Reader problem

[Vandil X]

At the end of the article, it is revealed that the exploits are Adobe Reader problems that are going to be addressed starting with Adobe Reader 10. So people that do not use Adobe's Reader client to view PDFs are not at as much risk, depending on how their non-Adobe PDF-reader solution is configured.

Of course, we all know the vast majority of the world (especially corporate users) uses Windows, and thus, Adobe Reader, so the security problems mentioned in the article are a valid cause for general concern... But not a concern for the PDF format in general.

Thank jebus that Apple invented Preview

[arcite]

Go figure, Preview works like butter in Mac OS X, yet the latest version of Adobe Reader is sluggish and jaggy while rendering the SAME PDF. You know, if it were not for Steve Jobs speaking out on Flash, Adobe wouldn't be doing anything to improve the performance/security of their software.

Re:Thank jebus that Apple invented Preview

[jimicus]

Indeed. You know what the easiest way to fuck with OS X is?

Treat it like Windows and install all the extras you'd want on Windows - even where equivalent functionality is already built in on OS X.

A couple of years ago I saw a MacBook Air that my US colleagues had purchased and done exactly that with. Even removing Adobe Reader sped it up no end.

Re:Thank jebus that Apple invented Preview

[John Hasler]

> Is ePDFview in the Debian repos?

Yes.

Re:All right

[AaronW]

I happen to know Julia Wolf personally and I know she's not seeking publicity. In talks I've had with her in the past, she has described how open PDF is to attack and how bad Adobe's reader is at security. She designs and writes these attacks as part of her job in order to detect and block them. She's one of the white hats. I'm sure that the issues she's discussed were probably discussed previously with Adobe and a handful of other security researchers, hence "previously hardly known". The article is poorly written IMO.

Trying to say that she's a publicity-seeking person would be highly inaccurate. She does give talks at various security conferences around the world since that is her expertise and she knows what she's talking about.

The problem is that Adobe made PDF so flexible with so many features that it's impossible to block all the various exploits, not to mention that Adobe themselves don't have a very good track record with security, i.e. look at Flash. The fact that PDF can incorporate Javascript, Flash, multimedia and even execute arbitrary external programs makes it a nightmare to secure.

Re:Ban manuals distributed in pdf.

[AaronW]

HTML manuals suck for a number of things. They don't print very well and are limited to a certain set of fonts. While there's SVG, it's not widely used at this time in the web browser because some browsers only recently started to support it (i.e. I.E.).

PDF as a standard vs a Standard for Documents

[DrTime]

Many years ago there was a standard in development called Open Document Architecture (ODA - ISO 8613) which defined a compound document standard which never became mainstream. Adobe's PDF was a proprietary product which became a mainstream standard encompassing content and presentation. The features described for a PDF are things some users will find a benefit. Good. What is upsetting is that these features are opaque. I don't know if everything dreamed of for ODA is in PDF, but PDF has solved many exchange problems with documents.

SGML (ISO 8879) offered a transparent document architecture which has been fragmented into HTML, XML, and its derivatives. A good set of SGML like tools should accomplish all of what is buried in a PDF but with transparency. We often confuse products, tools, standards,and technology and use the wrong product's technology as a tool. For example, I been given Microsoft Word DOCX files which would not work properly in Open Office and which could have been delivered as a PDF form or a simple DOC file.

There is nothing wrong with making the PDF file so powerful and providing simple tools (the reader) for people to open them. To me, the argument is over transparency. I may want to know what is inside a document that is being hidden from me. That is a matter of trust. The issue being addressed is trust and can we trust the PDF.

Re:Ban manuals distributed in pdf.

[munch117]

It would be good to have HTML standard for manuals - and have a standard to embed images and fonts and whatever in ONE SINGLE file (the same .html), then it will replace PDF to some degree.

You mean like MHTML? Based on MIME, standardised. Unfortunately Firefox doesn't support it out of the box, perhaps because it's a Microsoft invention (AFAIK).

PDF is hacker-friendly way of making leaks

[shoppa]

I'm not so sure what anyone is in such a huff about. PDF is very hacker-friendly, and the confusion that the general public has in their belief that a PDF is just a "printer ready" format (as opposed to a general purpose vector-graphics, text, and programming environment) ALWAYS works to the hacker's benefit and never to "big brother's" benefit.

Perfect example: when the TSA's army of contractors "redacted" a document for public release, they simply drew (in PDF) black rectangles above the redacted text. Yet the original text was still there and intact.

Some here seem to view content that's below the surface (not visible with standard settings on standard Adobe tools) as a problem. Yet it is the perfect route to security leaks, a treasure-trove to anyone who knows how to look below the surface. And we hackers are the ones who know how to do that.

Re:PDF is hacker-friendly way of making leaks

[jklovanc]

This is in the same vein as someone running "rm -rf" on a hard rive full of sensitive information and then selling it. Anyone with a little tech experience knows that the data is still there. Ignorance of how a system works is not a problem wit the system; it is a problem with the user.

PDF/A, PDF/X

[drolli]

There are two standards which are made for archiving/printing, where all the funny things are disabled and all the necessary thing are mandatory on board. How about not using the PDF standard when creating legal documents or other 100% perfect reproductions but PDF/A or PDF/X.

Everybody knows that PDF, as all formats which contain active (and nearly arbitrary) content are insecure.

It all depends on the Reader

[Nom du Keyboard]

It takes a PDF Reader to implement all of these tricky features. Hey, had I designed the PDF standard I might have put in all of these cute features as well once upon a time. Now we need either a Reader Lite that only renders the text, or an option to Disable All Cuteness.

Or a truly effective sandbox environment since this has proven itself very harmful.

Or a new Safe PDF format that eschews all of the cuteness. Take you pick.