Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Detailing the Security Risks In PDF Standard

Soulskill posted more than 3 years ago | from the many-and-varied dept.

Security 136

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

cancel ×

136 comments

Abomination (3, Funny)

panaceaa (205396) | more than 3 years ago | (#34736144)

"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 (3, Funny)

DamonHD (794830) | more than 3 years ago | (#34736162)

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

Rgds

Damon

Re:Abomination (4, Insightful)

QuoteMstr (55051) | more than 3 years ago | (#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:Abomination (2, Informative)

Anonymous Coward | more than 3 years ago | (#34736670)

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

Anonymous Coward | more than 3 years ago | (#34737182)

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

Re:Abomination (0)

Anonymous Coward | more than 3 years ago | (#34738924)

Thanks! Been looking for these.

Re:Abomination (1)

bytesex (112972) | more than 3 years ago | (#34737510)

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.

Re:Abomination (0)

Anonymous Coward | more than 3 years ago | (#34738088)

No I didn't purposely misunderstand anything, your example is where the document contains different values depending on sub-document read. I can't see how that higher level archive containing multiple document changes that. The publisher could still provide multiple versions with differing values. If the issue is about being able to see those multiple versions, then that's an issue for the reader software and not the format itself.

Realistically though it makes no real difference. If the publisher wants to charge the french different to the germans they are quite welcome to, if they want to keep that private between those two parties, then they'd just publish an individual file for each and not provide the others. That isn't a security issue.

Re:Abomination (1)

rjstanford (69735) | more than 3 years ago | (#34738814)

In fact, assuming that differences existed, being able to examine a single, signed file and determine that they were placed in there is probably more convenient than having to examine multiple files. Of course, you could distribute those multiple files in a signed archive, but that's basically what the PDF has become at this point.

Re:Abomination (1)

Korin43 (881732) | more than 3 years ago | (#34739466)

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?

Re:Abomination (4, Funny)

camperslo (704715) | more than 3 years ago | (#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.

Re:Abomination (3, Funny)

BitterOak (537666) | more than 3 years ago | (#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:Abomination (3, Insightful)

Anonymous Coward | more than 3 years ago | (#34736188)

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 (4, Informative)

Xugumad (39311) | more than 3 years ago | (#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.

Re:Abomination (0)

Anonymous Coward | more than 3 years ago | (#34736520)

Yes, thanks for the link. That's what I thought the whole PDF was for.

Ah, I see, they are intending to embrace and extend into other fields almost nobody currently uses it for.

As for what you are trying to do, what's the advantage over normal HTML?

Re:Abomination (1)

Xugumad (39311) | more than 3 years ago | (#34737748)

There's a few contexts we use PDFs in, with varying advantages:

1. For archival purposes, we produce signed PDFs (and are working on producing PDF/A compliant documents, but the library we're using is being a bit of a pest). These can't then be changed without breaking the cryptographic signature.

2. For coursework submission... HTML could work for essays (although conversion from Word has always been "interesting"), but presentations wouldn't work. We're idly looking at adding .docx to HTML convertors as a step towards turning essays into .epub or .mobi files for Sony/Amazon e-readers, but that's long term stuff.

3. For formal letters (e.g. the same system can produce "You're failing your degree" letters), where layout is important (and easier to get right in PDF, mostly).

Re:Abomination (1)

icebraining (1313345) | more than 3 years ago | (#34740174)

1) Any file can be signed, it's just a matter of hashing and encrypting such hash with a private key. PGP and such have "sign file" buttons.

2) http://meyerweb.com/eric/tools/s5/s5-intro.html [meyerweb.com]

3) Why is text layout important in a letter?

Re:Abomination (2)

jklovanc (1603149) | more than 3 years ago | (#34738168)

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 (2)

butlerm (3112) | more than 3 years ago | (#34737746)

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

Re:Abomination (2)

Jah-Wren Ryel (80510) | more than 3 years ago | (#34737992)

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 (3, Interesting)

bcrowell (177657) | more than 3 years ago | (#34738164)

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

Re:Abomination (1)

butlerm (3112) | more than 3 years ago | (#34739270)

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.

Re:Abomination (2)

metrix007 (200091) | more than 3 years ago | (#34739480)

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 (2)

bcrowell (177657) | more than 3 years ago | (#34740244)

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/ [didierstevens.com] ) 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.

Re:Abomination (1)

metrix007 (200091) | more than 3 years ago | (#34740344)

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 how they actually deal with stopping attacks, and reader x is the only one that tries.

Re:Abomination (0)

Anonymous Coward | more than 3 years ago | (#34738774)

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

It's a real shame that nobody has come up with any type of metadata standard that works across operating systems. Computer programming is still so amazingly primitive. We spend so much time trying to solving the same problem over and over and over again.

For example, you want to attach a grade to a file, so you come up with a painfully complicated PDF hack that only works for one type of document and one type of grade. As other people have said, what if you want to attach a grade to a non-PDF file? What if you want to add digital signature from the submitter and the grader? What if you want to attach other type of metadata to the same file? Your scheme breaks down.

You're solving a problem that has already been solved ten thousand times. This is really simple stuff to solve once and for all time, if we would just get over the politics and egos and just agree on the standards.

Re:Abomination (1)

datapharmer (1099455) | more than 3 years ago | (#34737142)

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 be used by someone else unless you know what you are talking about.

Re:Abomination (0)

Anonymous Coward | more than 3 years ago | (#34736226)

There are many file formats which use content negotiation. PDF used to mean "portable document format" and it's primary selling feature was that a PDF looked the same everywhere. If I don't care about getting the exact same output everywhere, then I can use HTML or DOC.

Re:Abomination (2)

burne (686114) | more than 3 years ago | (#34736362)

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

jgrahn (181062) | more than 3 years ago | (#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.

Re:Abomination (1)

butlerm (3112) | more than 3 years ago | (#34737528)

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 format with Javascript automation tacked on as an afterthought.

If you take the scripting aspect out of Postscript, you are left with nothing. If you take it out of PDF, 99.9% of the world's PDF documents still display and print without a problem.

Re:Abomination (4, Informative)

TheRaven64 (641858) | more than 3 years ago | (#34737606)

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 (2)

butlerm (3112) | more than 3 years ago | (#34738190)

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 (1)

TheRaven64 (641858) | more than 3 years ago | (#34738230)

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 are not present in PDF.

Re:Abomination (1)

butlerm (3112) | more than 3 years ago | (#34739136)

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 Postscript printer driver) to PDF without running through a full blown Postscript interpreter first.

That is entirely apart from the fact that most Postscript generators do not generate much in the way of control flow. What nearly every Postscript driver does is generate a bunch of macros that expand to lower level operations of the sort that PDF supports. Very roughly speaking Postscript is to PDF as XSLT is to XML.

Postscript is like M4 on steroids. PDF/X doesn't have macro expansion (let alone control flow), which makes it trivial to process by comparison. All the operators are pre-defined and do exactly the same thing. Postscript files are a user defined menagerie of any operator the programmer finds convenient.

Re:Abomination (1)

John Hasler (414242) | more than 3 years ago | (#34736828)

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.

Re:Abomination (0)

Anonymous Coward | more than 3 years ago | (#34737414)

There IS one type of environmental accommodation I would LOVE to see: reflowing of the document to fit the computer viewing window - I HATE viewing PDF docs in the page-centric format most are hard-coded for, which seems to be about 99% of the PDF docs I have viewed. Getting rid of the constant panning/scrolling to view the info would be a huge boon for those of us viewing these docs on a computer - what a concept! Without that I will continue avoiding PDF forms of documentation any chance I get (and with all the other malware programmability potential, it seems I have other reasons for that avoidance...).

Re:Abomination (1)

jklovanc (1603149) | more than 3 years ago | (#34738246)

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.

Re:Abomination (0)

Anonymous Coward | more than 3 years ago | (#34736990)

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.

Generate a different file with the corresponding text in the other language/s.

PDF started jumping the shark once JavaScript was added and video and Flash in a "document" format pushed it over the edge.

Re:Abomination (1)

hedwards (940851) | more than 3 years ago | (#34737624)

Indeed, you rarely hear of trouble caused by the core function of providing a document across platforms. All the trouble I hear about is the javascript and the other features tacked on to make it cooler and more exciting.

Unfortunately, those features also make it a lot harder to secure and a lot easier to use for malicious purposes. Word documents had a similar problem. Macro viruses didn't come on to the scene until MS decided that a document should be more than just text and mark up.

Re:Abomination (2)

WWWWolf (2428) | more than 3 years ago | (#34737086)

"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 (1)

netsharc (195805) | more than 3 years ago | (#34737724)

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!

Re:Abomination (2)

ColdWetDog (752185) | more than 3 years ago | (#34738414)

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 (1)

jklovanc (1603149) | more than 3 years ago | (#34738316)

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 problem of the user. Going by this logic there would only ever be one version of software.

Re:Abomination (1)

noidentity (188756) | more than 3 years ago | (#34737210)

Perfect for writing a two-faced contract.

Adobe Reader (1)

dna_(c)(tm)(r) (618003) | more than 3 years ago | (#34736196)

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.

Agreed. This is an Adobe Reader problem (3, Informative)

Vandil X (636030) | more than 3 years ago | (#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.

Re:Agreed. This is an Adobe Reader problem (1)

rudy_wayne (414635) | more than 3 years ago | (#34737206)

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.

Re:Agreed. This is an Adobe Reader problem (1)

metrix007 (200091) | more than 3 years ago | (#34739542)

version 10 has been out for a while now.....

Thank jebus that Apple invented Preview (2)

arcite (661011) | more than 3 years ago | (#34736274)

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 (1)

Larryish (1215510) | more than 3 years ago | (#34737184)

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.

Re:Thank jebus that Apple invented Preview (1)

Mr. Slippery (47854) | more than 3 years ago | (#34737520)

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.

Re:Thank jebus that Apple invented Preview (1)

Larryish (1215510) | more than 3 years ago | (#34737566)

Is ePDFview in the Debian repos?

Re:Thank jebus that Apple invented Preview (2)

John Hasler (414242) | more than 3 years ago | (#34738472)

> Is ePDFview in the Debian repos?

Yes.

Re:Thank jebus that Apple invented Preview (1)

Chaos Incarnate (772793) | more than 3 years ago | (#34737398)

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.

Re:Thank jebus that Apple invented Preview (1)

ColdWetDog (752185) | more than 3 years ago | (#34738434)

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.

Re:Thank jebus that Apple invented Preview (1)

Chaos Incarnate (772793) | more than 3 years ago | (#34739714)

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

Re:Thank jebus that Apple invented Preview (2)

jimicus (737525) | more than 3 years ago | (#34737626)

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 (1)

tsa (15680) | more than 3 years ago | (#34738032)

Foxit works better on Windows than Adobe Reader.

Re:Adobe Reader (1)

Alex Belits (437) | more than 3 years ago | (#34736356)

People use Adobe Reader?

All right (1)

Anonymous Coward | more than 3 years ago | (#34736214)

"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 (4, Insightful)

AaronW (33736) | more than 3 years ago | (#34736326)

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:All right (1)

TheHorse13 (908512) | more than 3 years ago | (#34736888)

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

Re:All right (0)

Anonymous Coward | more than 3 years ago | (#34738234)

From the very getgo, Adobe and Macromedia made it painfully clear that they were not going to address public concern for security. Buffer overflows were one of the first lapses that went unchecked for years while design & implementation surrounded this lack of security, seemingly to perfection while the landing platforms were designed to come into the back doors of everyone's PCs.

Ban manuals distributed in pdf. (1)

jack2000 (1178961) | more than 3 years ago | (#34736220)

What happened to good old HTML manuals eh?

Re:Ban manuals distributed in pdf. (0)

Anonymous Coward | more than 3 years ago | (#34736258)

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.

Re:Ban manuals distributed in pdf. (1)

realityimpaired (1668397) | more than 3 years ago | (#34736266)

You actually can do that with javascript, but it makes for a very large and clunky file.

Re:Ban manuals distributed in pdf. (1)

jack2000 (1178961) | more than 3 years ago | (#34736284)

It's a bad idea anyway. If you wanted to go that route you can use chm(Microsoft's proprietary compiled html help manuals)
You really shouldn't. Better to keep images in separate files. Noting stops you from having a simple web1.0 style webpage with hyperlinks to different parts of the same web page, or you can even break it into separate different files. You just need to link to it from the start menu or something. Name the main file help.html

Re:Ban manuals distributed in pdf. (0)

Anonymous Coward | more than 3 years ago | (#34736344)

Multiple files, folders, and images - for a manual? No, it has to be a single file with the option to 'explode it' for those like you, who prefer every single items as single files.

Re:Ban manuals distributed in pdf. (0)

Anonymous Coward | more than 3 years ago | (#34736776)

Whoa I just had a fantastic new idea that I guess nobody ever thought of! we could embed the files in an archive container so its just one file to transfer but when you look inside for the content you find everything in sections..

Re:Ban manuals distributed in pdf. (1)

spottedkangaroo (451692) | more than 3 years ago | (#34736430)

You can indeed embed the images. if memory serves.

Re:Ban manuals distributed in pdf. (2)

munch117 (214551) | more than 3 years ago | (#34736574)

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 [wikipedia.org] ? Based on MIME, standardised [ietf.org] . Unfortunately Firefox doesn't support it out of the box, perhaps because it's a Microsoft invention (AFAIK).

Re:Ban manuals distributed in pdf. (2)

AaronW (33736) | more than 3 years ago | (#34736346)

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

Re:Ban manuals distributed in pdf. (1)

jack2000 (1178961) | more than 3 years ago | (#34736398)

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.

Re:Ban manuals distributed in pdf. (1)

Anonymous Coward | more than 3 years ago | (#34736496)

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.

Re:Ban manuals distributed in pdf. (0)

Anonymous Coward | more than 3 years ago | (#34737486)

And since I prefer to view my manuals online, PDF is horrible since it is a print format. I am sick and tired of having only PDF manuals to find important information, having to constantly pan and zoom to get info that I could see in HTML much more easily (IF the HTML is not in some wonky format that has the same issues needing to be zoomed/panned to see the doc completely).

I hardly every print manuals/pages. Why do we have to be stuck with that archaic worst-case scenario?

RO

Re:Ban manuals distributed in pdf. (1)

AaronW (33736) | more than 3 years ago | (#34739414)

I never have a problem finding information in PDFs, nor do I always have to pan and zoom. I'm always dealing with datasheets for various chips and whatnot. These are ALWAYS in PDF format without exception from every vendor I've seen. They usually contain scalable vector drawings where they can't really do that in HTML because a certain company's web browser didn't support SVG until very recently. These PDFs also usually have have the table of contents as well to help navigation.

In my case I usually use Okular to read them.

Also, I don't have to be online to read them. Often these are saved locally. At times it can also be nice to print them out so I don't have to have it open on my screen to reference while working on code.

Re:Ban manuals distributed in pdf. (1)

panaceaa (205396) | more than 3 years ago | (#34736632)

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!

Re:Ban manuals distributed in pdf. (1)

jack2000 (1178961) | more than 3 years ago | (#34736692)

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

this is about samsung (-1)

Anonymous Coward | more than 3 years ago | (#34736302)

I appeal to everyone.

My name is Jinyoung Lee and I am a resident of South Korea (ROK). I am involved in an ongoing argument with Samsung Electronics, which is a huge multinational company, as a consumer. In May 2010, my Samsung cell phone (SCH-W830) spontaneously combusted in my home. It could have resulted in a fire, but I detected the event in its early stage. I contacted customer service at Samsung and reported the event. I was shocked by the attitude of Samsung, which should have addressed the problem.

From the beginning, Samsung engaged in the compensation process with insincerity. I was filled with anger because of the way I had been treated, so I went to the press with my story. Only then did Samsung start to respond. They did not, however, investigate the causes/sources of the spontaneous combustion; they even did not set out to clarify who was responsible. The only thing that they wanted was to keep me from informing the press. They gave me $4,000, which I had never asked for.

This did not end the case, however, several articles based on Samsung’s account of the story appeared in the newspapers. According to the article, I was a typical “black-consumer” [This term refers to consumers who file a vicious complaint on purpose]. They harmed my reputation to protect their brand image and themselves.

Because of my frustration, I put on a one-man demonstration, the only means by which I could expose their wrongful behavior in various places for 40 days. Their response was to sue me for libel. That means that they initiated criminal proceeding against me [In Korea, libel is both criminal and civil offenses].

Samsung is a huge company, and thus it is possible that it wields power over public institution. The police, who we can assume to be influenced by Samsung, investigated but exclusively on behalf of Samsung. I sued the Samsung Electronics in return to protect myself and the case was quickly dismissed for no reason. The police did a “search and seizure” of my house in Dec, 2010 and they mentioned the possibility of imprisonment-investigation. This procedure is not typical for a libel case in Korea.

Above all, Samsung wants to hide the truth about operation and their anti-consumer attitude, and so they are suppressing a consumer who exposes their actions to protect my right and interests as a consumer. So far, I have tried to inform the public about Samsung’s irresponsible actions, and I hope more people will come to know/understand this. I believe it will be one way to correct Samsungs’ wrong business behavior.

What I want is a sincere apology. What I want is official recognition of what they did to me. If my hopes are not fulfilled, then Samsung’s wrong business manner will continue. Of course, it will fall on those of us who might use Samsung products, which are selling like hot cakes. Ultimately, it is not a private issue and it is not limited to one consumer. I would like to say that it is an issue related to justice in dealing between a major company and consumers. We are consumers. Even though, they have more power than we have, we can exert our influence on
them as consumers. I need your attention. I believe that through you concern, I will finally achieve justice.

Thank you.
Best regards, Jinyoung Lee.

Re:this is about samsung (1, Funny)

MichaelSmith (789609) | more than 3 years ago | (#34736316)

Samsung cell phone (SCH-W830) spontaneously combusted in my home ... might use Samsung products, which are selling like hot cakes

No kidding!

Re:this is about samsung (0)

Anonymous Coward | more than 3 years ago | (#34737050)

You'd have better luck assembling an Angry mob if you swapped Samsung for Apple when making up that story. Samsung just doesn't get the emotions as high as Apple does.

PDF as a standard vs a Standard for Documents (2)

DrTime (838124) | more than 3 years ago | (#34736504)

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:PDF as a standard vs a Standard for Documents (1)

butlerm (3112) | more than 3 years ago | (#34737986)

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 that without pixel perfect rules for layout, stylesheets, and font embedding. It is not likely to ever be a viable replacement for what PDF is good for, even with some sort of super container format. It is not like one can go anywhere on the web and download pixel perfect specification for the ultimate HTML / CSS layout engine. HTML layout is half specification and half folklore. Obviously extremely useful, just much more complex than PDF is.

Entirely different levels of abstraction make PDF rendering trivial compared to writing a good HTML/CSS layout engine. The layout has already been done by higher level tools, down to the level of exact page coordinates. Different kind of format good for different kind of things.

PDF is hacker-friendly way of making leaks (5, Insightful)

shoppa (464619) | more than 3 years ago | (#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.

Re:PDF is hacker-friendly way of making leaks (-1, Troll)

interval1066 (668936) | more than 3 years ago | (#34736952)

What are you, retarded?

Re:PDF is hacker-friendly way of making leaks (0)

Anonymous Coward | more than 3 years ago | (#34737280)

At this moment, he is clearly informative.

Re:PDF is hacker-friendly way of making leaks (1)

Thundersnatch (671481) | more than 3 years ago | (#34737266)

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

Re:PDF is hacker-friendly way of making leaks (1)

shoppa (464619) | more than 3 years ago | (#34737462)

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 previous standards for "depth".

We have to watch out, because pretty soon just knowing of the ctrl-A, ctrl-C, Ctrl-V sequence is going to be tantamount to knowing how to build a blue box. Maybe just like we distinguish "hacking" from "phreaking", maybe we should distinguish mining PDF's or MS-Word .DOC's for hidden information from hacking? Hmm... PdFreaking? PreaDFing?

Re:PDF is hacker-friendly way of making leaks (0)

Anonymous Coward | more than 3 years ago | (#34737866)

Repent.. for the time is near!

Re:PDF is hacker-friendly way of making leaks (1)

Gothmolly (148874) | more than 3 years ago | (#34737896)

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

Re:PDF is hacker-friendly way of making leaks (1)

ian_from_brisbane (596121) | more than 3 years ago | (#34738502)

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

Does he call himself gothmolly?

Re:PDF is hacker-friendly way of making leaks (2)

jklovanc (1603149) | more than 3 years ago | (#34738082)

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.

Re:PDF is hacker-friendly way of making leaks (1)

yuhong (1378501) | more than 3 years ago | (#34740026)

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.

Let's abandon this outdated standard (1)

Anonymous Coward | more than 3 years ago | (#34736774)

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

PDF/A, PDF/X (2)

drolli (522659) | more than 3 years ago | (#34737198)

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.

Re:PDF/A, PDF/X (0)

Anonymous Coward | more than 3 years ago | (#34737298)

Do you know of any good PDF/A (and PDF/X) only readers?

It is not so much the documents i produce I am worried about... it is what I get from the others.

PDF == EXE (1)

Anonymous Coward | more than 3 years ago | (#34738028)

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.

It all depends on the Reader (2)

Nom du Keyboard (633989) | more than 3 years ago | (#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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...