Forgot your password?
typodupeerror
Security IT

Detailing the Security Risks In PDF Standard 136

Posted by Soulskill
from the many-and-varied dept.
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."
This discussion has been archived. No new comments can be posted.

Detailing the Security Risks In PDF Standard

Comments Filter:
  • Abomination (Score:4, Funny)

    by panaceaa (205396) on Sunday January 02, 2011 @06:26AM (#34736144) Homepage Journal

    "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.

    • by DamonHD (794830) <d@hd.org> on Sunday January 02, 2011 @06:30AM (#34736162) Homepage

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

      Rgds

      Damon

      • Re:Abomination (Score:5, Insightful)

        by QuoteMstr (55051) <dan.colascione@gmail.com> on Sunday January 02, 2011 @06:39AM (#34736202)

        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: (Score:2, Informative)

          by 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

          • Re: (Score:2, Informative)

            by Anonymous Coward

            A recording of the presentation will soon appear here [ftp.ccc.de] and should answer your request for more details.

          • by bytesex (112972)

            No, the higher level is going to be an archive file with multiple PDFs and a manifest giving you the details of what is for whom. But then, you purposely misunderstand, I suspect.

            • by Korin43 (881732)

              I don't see how that's better. If I always open the English documentation anyway, what's wrong with my computer picking it automatically?

          • by doom (14564)

            You might imagine valid uses for flexible documents that adapt to the environment they're read on, but if you don't realize that these documents have these flexible/adaptive features, then there is indeed some potential for nasty surprises.

            There are already a lot of weird myths about pdfs (e.g. I've heard they're better for contracts than docs because "pdfs can't be edited"). This is, at the very least, pointing out yet another misconception.

        • by camperslo (704715) on Sunday January 02, 2011 @03:10PM (#34738844)

          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.

          • by BitterOak (537666) on Sunday January 02, 2011 @04:50PM (#34739410)

            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: (Score:3, Insightful)

      by 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 (Score:5, Informative)

        by Xugumad (39311) on Sunday January 02, 2011 @07:28AM (#34736342)

        > 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 [wikipedia.org] ), 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/ [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.

        • by butlerm (3112)

          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 [wikipedia.org].

          • by lahvak (69490)

            Ehm, can you please point out where on the page you link to does it say that the sole intent of pdf format was originally to produce printed documents? I don't seem to be able to find that.

            • by butlerm (3112)

              You can always go read the PDF 1.0 specification, which is what I did, in 1993 or so. Of course no one was promoting the idea that you had to reduce the documents to hard copy. Acrobat Reader would be pretty useless if that was the case.

              • by lahvak (69490)

                I cannot find pdf 1.0 specification online, but I did find pdf 1.2 from 1996, and it describes the purpose of the format as "to enable users to easily and reliably exchange and view electronic documents independent of the environment in which they were created." It says nothing about hardcopy, and it specifically talks about "electronic documents", without further specifying what these are. It also says that "PDF also includes objects, such as annotations and hypertext links, that are not part of the page

                • by butlerm (3112)

                  I misspoke when I said "printed documents". I should have said something like "print-ready page oriented documents". Form support was bolted on three years later, and the sort of forms that PDF was good at were "print ready page oriented documents", like IRS tax forms, for example.

                  It is not a mistake that audio, video, and Flash support didn't come to PDF for twelve years after that. That is not what the creators had in mind, or at least not what they expended any actual effort implementing. What they

                  • by lahvak (69490)

                    I agree with you on the difference between pdf and html. Thus the need for a format that is page oriented, allows us to deliver document in a typographical quality, but allows interactive content. Pdf tries to do that.

                    Javascript came to pdf in 2000, the same year as prepress support. Does it mean that pdf document were never meant to be seriously printed in high quality, since it took 7 years to introduce prepress support?

                    • by butlerm (3112)

                      No, for two reasons. (1) For most common applications PDF was high quality (2) PDF was based on a technology designed for typesetting from the very beginning. Adding the tweaks necessary for pre-press is a minor change.

                      Javascript support and interactivity was not, evidenced in part by the fact that dynamic PDF documents are incredibly rare. The whole tool chain used to produce most PDFs has no support whatsoever for automating them.

                      For the record, I think embedding audio and video clips is a worthwhile ex

              • by Xugumad (39311)

                Yeah, I went away and read the 1.2 spec. Hadn't realised how much stuff they added later to PDF. I suspect a lot of the problems are that it's been substantially over-expanded since original design.

        • 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 (Score:4, Interesting)

          by bcrowell (177657) on Sunday January 02, 2011 @01:37PM (#34738164) Homepage

          > 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 [wikipedia.org] ), 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/ [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.

          • by butlerm (3112)

            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.

            Clearly we need a 'PDF/R' then, much like PDF/A except without mandatory font embedding.

          • by metrix007 (200091)

            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.

            • by bcrowell (177657)

              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 of

              • by metrix007 (200091)
                No, Adobe Reader X is far, far more secure than either Foxit or Summatra or any other reader. Adobe Reader X, apart from haing the sandbox, is also the only reader to make use of Windows Integrity Controls so it is running in a low process by default. It is also the only reader to make use of DEP and ASLR, neither of which Foxit or Sumatra have ever tried to do. The javascript issue is not useful for comparison, as you noted others have js support and it can easily be disabled. The measure of security is ho
          • by Xugumad (39311)

            > 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.

            It's actually simpler and safer than you'd imagine. The plan would be to have the server pre-check the PDF, and outright refuse to put the field in if there's anything troubling (e.g. scripts). The grade field will be a normal text form field, and the whole PDF will have to be re-uploaded to the server to extract the value.

            > But what if

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

          Right, but world domination is hard to fit on the printed page. :-)

      • Having written a thesis on digital data archival, I can say with certainty that there are a number of different types of pdf including PDF/A which is intended specifically for archiving and does not have all this fancy nonsense in it like embedded videos transparent layers and switching of languages etc. It is well documented and has its own separate ISO number. While adobe does some crappy stuff to things that have a ".pdf" extension at times don't make dramatic conclusions about how something is unfit to
    • by burne (686114)

      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 programmi

      • Re:Abomination (Score:5, Interesting)

        by jgrahn (181062) on Sunday January 02, 2011 @08:28AM (#34736566)

        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.

      • by butlerm (3112)

        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

        PDF is not anything like PostScript. It shares the same rendering model, that is about it. Postscript _is_ a Forth-like, stack oriented programming language. PDF isn't a programming language at all, but rather a generally vector oriented graphics form

        • Re:Abomination (Score:5, Informative)

          by TheRaven64 (641858) on Sunday January 02, 2011 @12:16PM (#34737606) Journal
          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.
          • by butlerm (3112)

            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

            • PDF isn't based around an interpreter

              As I said, the top-level structure is a dictionary, but the drawing command set is definitely run in an interpreter. It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript. In the first version of the PDF spec, it was a subset of PostScript, just with the flow control removed. In newer versions, it has gained some things that

              • by butlerm (3112)

                It provides a set of stateful drawing commands which are identical to the same commands in PostScript. It is not a Turing-complete language, because it doesn't have loops, but it is interpreted and its syntax is identical to PostScript.

                A syntax identical to a highly restricted subset of PostScript - not so much as a user defined macro - everything pre-defined for you. You can't even come anywhere close to converting the most average, run of the mill Postscript file (such as the output of a typical Postscri

    • 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?

      Not me, certainly. When I view a document I want to see exactly what everyone else viewing the document sees unless I take explicit action to change it.

      • by jklovanc (1603149)

        Lowest common denominator. So you don't care that some systems are more compliant that others and can display things better than others. That would require the format to only support formatting that available on all computers.

    • by WWWWolf (2428)

      "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 bound

      • by netsharc (195805)

        I suppose they could put a big page in the front that only appears on older reader version that says "This document contains the documentation to GarageBand in X languages", ... etc etc, but then again, who uses brains in this area.

        Or prevent printing if the reader doesn't have "multi-language" capabilities... yay, frustrate the user even more!

        • 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.
      • by jklovanc (1603149)

        Try opening a Word 2010 in Office 3.1. It won't work. The fact that the PDF was even able to be opened in older software is astounding. One would have to be clairvoyant to be able to make software compatible with all possible future extensions.

        To me this sparks a hubris; I want the computer to do what I want when I want no matter what version of software I use. The fact that someone opens a new version document in an old version of the software and there is an issue is not the problem of the software but a

    • Perfect for writing a two-faced contract.
    • There is a place for adapting to the user (though IMO there should always be overrides). But there is also a place for a standard "electronic paper" that reliablly displays the same way everywhere. Many people assume PDF is like electronic paper but as the article shows it isn't in key ways.

      Consider what happens if someone reads a document, decides they agree then takes it to another system to print and sign. There is no gaurantee that what they read matches what they printed and signed.

  • Still looks more like it requires Adobe Reader to be a problem. I've seen other things from Adobe, they're about pretty things, not security.
    • by Vandil X (636030) on Sunday January 02, 2011 @07:05AM (#34736272)
      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.
      • 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.

        From TFA: "Adobe plans to remedy the situation in version 10 of its Reader product by introducing a sandbox". In other words, they aren't going to actually fix any of the problems, they're just going to try to hide them behind a wall.

      • by lahvak (69490)

        Actually, there are many more powerful alternative pdf readers on windows than on linux. On linux, if you want anything besides just a document rendered to print (such as annotations, animations, forms, 3D content, ...), you have to use adobe reader. I don't know what the situation is on osx, but state of linux pdf readers is abysmal. Linux is perfect environment for producing pdfs, but linux viewers are really quite primitive.

    • 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.
      • by Larryish (1215510)

        Evince on Linux is the same way.

        Adobe's own offering is slow and eats up memory.

        Evince loads large PDF files in less than 3 seconds and uses a comparatively small amount of memory. Scrolling is smooth, as well.

        • Evince loads large PDF files in less than 3 seconds and uses a comparatively small amount of memory. Scrolling is smooth, as well.

          Even evince is starting to suffer from bloat. I've recently gone back to using xpdf [foolabs.com] on my desktop box, and put ePDFView [fsf.org] on my netbook.

      • Preview has a nasty habit of not displaying the PDF correctly, though. I'd rather slow-and-correct than fast-but-graphic-elements-get-randomly-shifted-on-the-page-or-dropped-entirely.
        • Preview has a nasty habit of not displaying the PDF correctly, though. I'd rather slow-and-correct than fast-but-graphic-elements-get-randomly-shifted-on-the-page-or-dropped-entirely.

          The couple of times I've had issues with Preview not displaying a PDF file, I have noticed that even in the full (OS X) version of Acrobat, the file is pretty wonky. I'm not sure that Adobe even knows what Adobe is doing.

          • I can't say that I've noticed that - it's always been fine in Acrobat. Then again, in those cases I've gone back to Acrobat on Windows, rather than installing Adobe Reader on my OS X machine, which might explain it...
        • I have never seen this with a well-formed PDF. In fact, Preview is the reference PDF renderer for several graphic artists I know precisely because Acrobat seems to produce funny output with a significant minority of files.

          • Well, I can't guarantee that the PDFs I've had problems with are well-formed. But since they're from outside sources, not much I can do about them besides use a renderer that works (Acrobat) instead of one that doesn't (Preview). :)
      • by jimicus (737525)

        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.

      • by tsa (15680)

        Foxit works better on Windows than Adobe Reader.

    • by Alex Belits (437) *

      People use Adobe Reader?

  • by Anonymous Coward

    "previously hardly known"

    And that's where I stopped reading. Yet another publicity-seeking person recycling previously known vulnerabilities and trying to tell us they were "hardly" known.

    • Re:All right (Score:5, Insightful)

      by AaronW (33736) on Sunday January 02, 2011 @07:24AM (#34736326) Homepage

      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.

      • "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" You mean like that pesky Winders operating system?
  • What happened to good old HTML manuals eh?
    • by AaronW (33736)

      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.).

      • by jack2000 (1178961)
        HTML manuals print PERFECTLY. Fonts shouldn't be a concern for manuals. If you are using funky fonts in your help files you are doing it wrong. If you need special notation you can use utf or latex.
        • by Anonymous Coward

          HTML is a display format, not a printing format. It will print, but often poorly formatted - the reason for using PDF over txt/html is that they want it to look pretty/have a fixed display format relative to images, etc. HTML is nice for linkability, but a printed out HTML manual is utter crap to flip through.

    • by panaceaa (205396)

      HTML manuals can do all the things accused of PDFs, and you won't even know about half of them! Your browser automatically sends your operating system and locale preferences on every request. The hosting site doesn't even need Javascript to access them. But if you did have Javascript enabled, your HTML documentation could also read and write to Flash and HTML5 offline storage databases, often without your consent or direct knowledge! The horrors!

      • by jack2000 (1178961)
        Which is why browsers should(some do already) implement sensible restriction policies on per zone and site level. Like preventing local pages from accessing the internet unless you specifically allow them.
        Further all the hard to remove cookie shenanigans could be fixed, but wait Flash? That's ADOBE's fault again! DOH.
        HTML5 offline storage should be cleared from the same privacy clearing settings that cookies are cleared from etc.. etc..
  • 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

    • by butlerm (3112)

      A good set of SGML like tools should accomplish all of what is buried in a PDF but with transparency

      SGML is two full levels of abstraction higher than PDF. PDF isn't really intended to be a user editable document format at all. PDF is a page description language with a few extra features glued on. It was never intended to be editable, let alone provide any sort of document structure (aside from a table of contents), but rather to provide an accurate representation of printed pages.

      SGML and HTML cannot do

  • by shoppa (464619) on Sunday January 02, 2011 @09:00AM (#34736690)
    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.

    • The ability to press Ctl-A, Ctl-C, switch to a text editor, and press Ctl-V does not qualify you as a "hacker".

      • by shoppa (464619)

        The knowledge that there is something actually informational there below the surface of glitz, is hacking in a way.

        At one point I was sure that hacking - knowing what was going on below the surface - was by definition the ability to wire a flip-flop together and later to code in machine code and then Fortran. And using this to, say, put something up on the Rose Bowl scoreboard.

        Today I am willing to enlarge that to typing Unix shell commands, and extracting hidden text from PDF's. Yes, both are relaxing the

      • Neither does the ability to program qualify a person as a hacker. A hacker is somebody who thinks outside the box, with playfulness and creativity.

      • Similarly, many non-hackers have the knowledge to open a file in a text editor. There can be some interesting stuff there, quite apparent.

    • by Gothmolly (148874)

      A real hacker doesn't call himself a hacker, you tool.

    • by jklovanc (1603149)

      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.

    • by yuhong (1378501)

      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.

      Yep, the difference between vector and bitmapped graphics.

  • by Anonymous Coward

    And start using something more modern and much more secure: XPS.

  • by drolli (522659) on Sunday January 02, 2011 @10:52AM (#34737198) Journal

    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.

  • by Anonymous Coward

    And woe unto those who do not treat it as such in their security model.

    If you consider the social aspect of it, its even worse...many users will not run random programs sent even from well spoofed messages, but a "document" is as close to a thoughtless decision as you can find.

  • by Nom du Keyboard (633989) on Sunday January 02, 2011 @02:16PM (#34738460)
    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.

"Tell the truth and run." -- Yugoslav proverb

Working...