How many ways can a PDF mess up your PC? 47 in this Adobe update alone Adobe has posted security updates for Acrobat, Reader, and Photoshop, many of them critical fixes. The developer says the Acrobat and Reader update will address a total of 47 CVE-listed vulnerabilities, including two dozen remote code execution flaws in the PDF readers. Adobe notes that none of the bugs are being actively …
For my sins I’ve spent a considerable proportion of the last six years or so engaging with PDF as a file format in a disturbingly intimate manner. I’ve come to the conclusion that if somebody specifically set out to custom design a delivery vehicle for malware you would probably end up with something looking a lot like PDF, and that’s before you consider the potential for vulnerabilities in the reader, the OS it’s running on, and any third-party library code it depends on...
I'm thinking using all those tools have resulted in a backlog of found flaws that will take them into the next decade. I must suppose that QA and testing are very important now, and perhaps rate-limiting, as coming up with fixes that don't break things is hard. (this is Adobe we're talking about - coding fixes well is way harder than coding features badly)
It is very, very hard to use tools to identify all of the defect sites in what is effectively legacy code - especially when no thought was given to writing the code in a way that would allow these sort of errors to be detectable (or prevent them in the first place).
In general, errors of this type are undecidable - this means tools will produce a mixture of valid detections, false-positives (i.e. "noise", and often a lot of it) and false-negatives (real issues that don't get reported).
Anyone that claims they have a tool that can catch all defects without false alarms is selling snake-oil.
Found one for you: CVE-2010-2575, mind you it was fixed 8 years ago so you can sleep well tonight.
Details:
Stefan Cornelius of Secunia Research discovered a boundary error during RLE decompression in the “TranscribePalmImageToJPEG()” function in generators/plucker/inplug/image.cpp of okular when processing images embedded in PDB files, which can be exploited to cause a heap-based buffer overflow. (CVE-2010-2575)
especially true on Linux, BSD systems
atril works pretty well for me. [evince now enforces 2D flatso look last I checked, won't touch with 10 foot pole]
(I had to go back and check what it was they did - was thinking '.Not' but it was a gtk 3 2d flatso look that irritated me)
Unfortunately, there are such things as encrypted PDFs which are protected with the "FileOpen" (hah) plugin (sadly all too common for academic articles), and for Linux users the plugin only exists for Acrobat Reader 8, and no newer versions(!).
And then you have people who don't like change and so still prefer to use Acrobat Reader rather than their browser's PDF viewer (or evince or okular).
And then you have the fact (I think, fortunately, less so, nowadays) that the PDFs of many academic articles were created by LaTeX, often using a, shall we say, "quirky" assorted of LaTeX packages, which all seem to try their best to tickle bugs in PDF viewers, requiring users to try several different viewers until they can find one which displays the document properly.
And then, the icing on the cake is that Linux printer drivers supplied by actual supposedly corporate printer/copier manufacturers get far less care and attention (yes, Xerox, I am glowering at you), so that even if you manage to display a quirky PDF, it's still a matter of luck as to whether it will actually print successfully from Linux. Sadly, although somewhat understandably, saying that remote-desktopping into a Windows computer and just printing the file from there is really by far the easiest and most viable work-around, doesn't tend to always go down very well.
You can, hypothetically, write good code in C++, the problem is that C++ is so incredibly complex, that most programmers only know a fraction of it very passingly. So typically they have little idea what their code does. Combine that with no memory safety and you get a recipe for disaster.
The few people actually knowing C++ don't write software (except for compilers), they tour the world teaching C++.
C has similar problems, but at least it's low level enough that you can understand what's happening and therefore know where to focus your attention on.
Actually today the ideal language for something like a PDF reader might actually be Delphi. There's now a full free cross-platform implementation around. It's got memory safety, integer bounds check, array bounds check, a platform independent GUI toolkit which looks native on every system.
@Christian Berger: "You can, hypothetically, write good code in C++, the problem is that C++ is so incredibly complex" ..
Dear Mr Berger,
I read your comment and was about to upvote when I came to this:
Actually today the ideal language for something like a PDF reader might actually be Delphi.
Crikey, NO! TurboPascal is nice for teens to learn how to program, that is all, though ... ;-) Nothing to do in a professional piece of software. I think we might have already discussed this on stackoverflow ? There cannot be more than one Delphi fanboy in this solar system, right ?
PDF is not _that_ bad, at least not if you use "archive grade" variants of it. You can cut down the featureset enough to be both safe and usable.
PS is an accident waiting to happen, as PS is actually turing complete code by design. So you'll likely be able to exploit things via it, even on completely correct implementations.
I mean, I have always hated PDF and Acrobat with irrational rage, but 47 vulns?
And, of course, just today I had to open PDF documents (on my PC and without a condom!) and (attempt) to fill out one of them and submit it to HR. Oh please. I can only hope that the wretched thing gave the creator herpes. What is wrong with an HTML form? Oh, wait, that would take more than a point-and-click mentality to create, so of course they're having none of that!
Better to heave bloated PDF around until everyone on the network is used to opening them without qualm, and then deal with the security breaches as they happen.
Sorry. Always hated Portable Document Fuxery. Always will, and glad of a chance to go off half-crocked about it.
13 use-after-free
7 heap overflow
1 double free
1 out-of-bounds write
1 type confusion
1 untrusted pointer dereference
All of these are machine level coding errors most of us have been making for at least 40 years. We should ask ourselves urgently why we're still so incompetent at coding before someone else demands that answer. Or is everyone so tolerant already of the garbage we call software that no-one will ever ask?
I think you are being somewhat rash in assuming that these are *new* bugs. I think it is more likely that the offending code was cut-and-pasted into place 10 or 20 years ago and today's patches are merely a measure of how long it took Adobe to realise that their codebase sucks.
Of course, for some of us it has been obvious for nearly 2 decades that there is something deeply, deeply wrong with the codebase, since it was ostensibly written in a portable language for a flat memory model and yet ports to other OSes or other bit sizes have apparently been impossible.
A port to a NIX would, for example, allow the use of free tools like valgrind that would find such problems statically. (And, with reference to the earlier post that worried about false positives, the solution there is simply to examine each on manually and either (i) re-write it, (ii) figure out why it is a false positive and then annotate it to suppress the message, or (iii) fix it. Put another way, you start at the beginning and work through to the end and if it takes 10 years then that serves you right for writing such shit in the first place.
It’s in our procurement rules now, even for “free” software and services
Vendor = ‘Adobe’ - authorisation rejected by IT. Marketing HATE us, but the board agreed with the presentation showing how much it really cost to maintain Adobe products including Acrobat Reader. We are now Adobe free.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
