PDF Vulnerability Now Exploitable With No Clicking 206
SkiifGeek writes "With Adobe's patch for the current PDF vulnerability still some time away, news has emerged of more techniques that are available to exploit the vulnerability, this time without needing the victim to actually open a malicious file. Instead, the methods make use of a Windows Explorer Shell Extension that is installed alongside Adobe Reader, and which will trigger the exploitable code when the file is interacted with in Windows Explorer. Methods have been demonstrated of successful exploitation with a single click, with thumbnail view, and with merely hovering the mouse cursor over the affected file. There are many ways that exploits targeting the JBIG2 vulnerability could be hidden inside a PDF file, and it seems that the reliability of detection for these varying methods is spotty, at best."
Not PDF vulnerability ... Adobe vulnerability (Score:5, Insightful)
Re:Not PDF vulnerability ... Adobe vulnerability (Score:5, Informative)
Adobe's particularly horrible implementation.
Right now, on my laptop, I have two VirtualBox sessions running images pretty close to the servers at work. I'm testing out some simulation. I've got slashdot open in Firefox, and I've got Adobe's PDF reader open to a reference manual.
The PDF reader is using more memory than the two virtual servers combined. That's a ridiculous amount of bloat, and it doesn't even count the "Adobe Updater" software that runs all the time.
Re: (Score:2)
Hmph. Doesn't surprise me. The Adobe Acrobat Reader setup pinned my CPU for a solid 5 minutes and consumed more memory than Firefox consumes even at its worst.
Re:Not PDF vulnerability ... Adobe vulnerability (Score:5, Informative)
Re: (Score:3, Informative)
Re: (Score:2)
Sumatra Reader can't select text.
Re:Not PDF vulnerability ... Adobe vulnerability (Score:5, Informative)
It's not obvious, but if you hold down the control key while mousing text is selected and automatically copied to the clip board.
Once you get used to it this is actually quite convenient.
Re: (Score:3, Insightful)
That's all PDF is for. I've lost count of the number of hours I've spent on the phone to users who imagine that editing PDFs with Acrobat Professional is going to be easy. The whole point of PDF is that it is an end-point document, viewable on screen or printable with a consistent format. It was never intended to provide a format designed for being edited.
That's where OpenOffice (or NeoOffice) has it right - providing a nice handy button to click to e
Re: (Score:3, Insightful)
I've lost count of the number of hours I've spent on the phone to users who imagine that editing PDFs with Acrobat Professional is going to be easy.
The problem is that people do not understand the difference between a text editor or word processor and a print layout or typesetting program. Acrobat is more like the latter and less like the former. If people understood a bit more about the different goals of these different programs then they would not be as surprised that it isn't easy to use a professional print layout tool just like they would use a word processor.
Re: (Score:2)
Now we just need a way to embed the PDF inside the OO.org document so we can get infinite recursion. Yay!
Re: (Score:2)
No, we just need to give Acrobat Reader the ability to send EMail, and then it will be done.
Re: (Score:2)
I don't understand this whole PDF thing.
That's the reason for your problems. Really.
Read it up. PDF is just PostScript in an envelope. Which is a very open and stardardized printer document language.
And it is text too. Although it embeds binary images, fonts and so on, too.
But you can open it with a text editor, and change stuff, just like you would do with HTML or TeX. Try it on an OpenOffice generated one, because the ocred/printed ones are often a horrible mess.
Re: (Score:2)
And it is text too.
Except when it isn't. If it's encrypted it's still PDF but you're not going to get much joy out of it with a text editor.
Re: (Score:2)
and the yellow page design hurts my eyes.
i couldn't find a feature list, but i assume that saving filled forms (or form support at all ?) isn't available.
while it has potential, feature parity and exceeding will be required to gain some serious marketshare.
Re: (Score:2, Informative)
Eh, it's buggy. I just installed it, and after 4 seconds figured out I can't even scroll with PDFs on "Facing" mode (how I primarily use PDFs).
Also there's no toolbar buttons like in Acrobat for changing the view.
I think I'll stick with Reader 7.0.x + ARSpeedup for now.
Re:Not PDF vulnerability ... Adobe vulnerability (Score:5, Informative)
(yes, there's a ton of good PDF freeware [paperlined.org] available now)
Re:Not PDF vulnerability ... Adobe vulnerability (Score:5, Interesting)
It's kind of a flaw that is endemic to the commercial software development model. This is not to say that that model is useless or F/OSS doesn't have its own problems.
The root of the problem is how we "add value" to a piece of software. Since with F/OSS, software development has a service model, you mainly add value by adding services: documentation, support, consulting. You can't "add value" by adding features to the software, at least if you try to you only get paid once for doing so.
A proprietary software developer can get paid multiple times for adding a piece of value into the software. For software that is sold, this is driven by market segmentation. The least pernicious form of this is the ubiquitous "bronze/silver/gold" model where they try to maximize their return from cheapskates, pragmatists and spendthrifts respectively. If you are cheapskate who needs a feature in the "gold" edition, you're out of luck. In the worst case, it drives a bewildering proliferation of "products", as vendors try to find the division of features that maximizes their returns (which is an instance of the NP-Complete "integer programming problem", only approximations are practical). From a customers standpoint, it sometimes looks like a whirlwind has picked up all the features and dropped them into random pigeonholes.
The "value adding" imperative still applies to free as in free beer proprietary software. In such cases, the developer still is looking to get paid, only in different coin, e.g. control of formats and the market power that comes with it. Adobe benefits from PDF being a non-proprietary format because it encourages adoption, but it is risky because they wouldn't benefit if they did not control the dominant implementations of PDF technology. And they try very hard, I think, to have the best implementations, which leads to the old problem of adding value by adding features. The hope is that by adding features nobody has asked for, when those features are missing from a different implementation, that implementation will be seen as less complete and polished. I think this often works, but it leads to this kind of blowback siutation: security flaws introduced to users systems along with features the user never asked for.
Re: (Score:2)
as vendors try to find the division of features that maximizes their returns (which is an instance of the NP-Complete "integer programming problem", only approximations are practical)
Deciding four-colorability of planar graphs is O(1)---that's the famous Four Color Theorem---so it's in P so it's in NP so it reduces to SAT, integer linear programming and god knows what else.
Does that mean that only approximations to "bool fourcolorable(graph_t *G) { return true; }" are practical? Return true some of the time? I think it looks perfectly practical. In fact, it scales perfectly to any number of graphs ;-)
If you're claiming that integer linear programming reduces to "Vista Segmentation" a
Re: (Score:2)
It's kind of a flaw that is endemic to the commercial software development model.
Yup, the true price of bloat.
Re: (Score:2)
Re: (Score:2)
Well, by default it will.
Firefox: Add-ons, Plugins, Adobe Acrobat, Disable.
Internet Explorer: Internet Options, Programs, Manage Add-ons, Adobe PDF Reader Link Helper, Disable.
Re: (Score:2)
Well, cancel that... the Firefox fix works, but IE still loads PDFs internally. I can't find a setting to stop that from happening. Somebody else have any idea?
Re: (Score:3, Informative)
Inside Adobe Reader (version 8 at least) under Tools|Preferences|Internet uncheck "Display PDF in browser" in the "Web Browser Options" group.
Re: (Score:3, Interesting)
It's really stupid that IE doesn't let you manage its behaviour when downloading a PDF.
Inside Adobe Reader (version 8 at least) under Edit|Preferences|Internet uncheck "Display PDF in browser" in the "Web Browser Options" group.
I'm seeing Preferences under Edit, not Tools.
Unfortunately, it still launches the PDF in Adobe Reader. That's no fix at all: malicious PDFs will still be opened automatically. There's apparently no way to have it prompt you to find out if you want to open, download, or not.
Re: (Score:2)
Or just don't use IE to browse the web. If you use Firefox and disable the Adobe plugin, it asks you what to do with the PDF exactly like it ought to (unless you define a default action – needless to say, the default action shouldn't be "Open with Adobe Reader"). If you've disabled the shell extension, you could even allow it to save by default, since the PDF could then safely be deleted if you didn't trust it.
'Course, you're still stuck with the possibility that an application might ignore your defau
Does it affect other platforms as well? (Score:2)
Since PDF is Portable, does it affect other platforms as well. Or is it Windows specific? Does it affect other libraries than the Adobe ones? And why the fsck does a freakin' DOCUMENT have scripting in it? I can understand form elements but not something akin to shell scripting.
Re: (Score:3, Informative)
does it affect other platforms as well. Or is it Windows specific?
Yes [slashdot.org] and no respectively. It only affects Adobe Reader. All other PDF software is unaffected, I believe.
Re: (Score:2)
and installing and using adobe reader speedup or adobe reader lite that has all the bloat stripped out solves the problem as well.
Honestly Adobe reader went downhill ever since 5.1 was released... 5.0 was the best after that they only have added in garbage.
Re: (Score:2)
I will take the risk and tell it. Adobe Reader 9 is one of the best performing and low CPU using PDF readers out there and I am writing this from a 1.42 Ghz G4 Mac Mini with 1G RAM installed.
It is real sad that because of the bureaucrats and some idiots at Adobe, one of the most serious multi platform security vulnerabilities happened just when Adobe Reader was heading right direction both in performance and UI wise.
I know what you mean by version 5 and I actually have it installed in a Quad G5 (via Tiger's
Re: (Score:3, Insightful)
"And why the fsck does a freakin' DOCUMENT have scripting in it? I can understand form elements but not something akin to shell scripting."
Can I assume that you're upset about HTML having all this stupid Javascript stuff, too? I mean, it's just for displaying and linking to information. It doesn't need 'something akin to shell scripting'.
Re: (Score:3, Interesting)
Can I assume that you're upset about HTML having all this stupid Javascript stuff, too?
I can't speak for the original poster, but I'm certainly happier since I installed the NoScript extension in Firefox. Slashdot was one of the main reasons that I installed it, as there was some script on the front page that used to freeze my browser for a few seconds for no good reason.
In a PDF "document" I sure as hell don't want any active scripts beyond the ones that are needed to generate the pixels I'm looking at. I can see a use for interactive forms and similar scripted things, but they should not be
So, don't use Adobe Reader (Score:2, Informative)
Use Foxit! Reader on Windows and something else on other operating systems, such as Okular.
Re: (Score:3, Funny)
Re: (Score:2)
Jumping from one uninspectable, unmodifiable proprietary PDF reader to another is not wise. Better to run more free software, not less. Pick a free software PDF reader for all of your computers so you can see what it will do, change it to meet your needs, and share your improvements with the community. Better still, run a free software OS so you can enjoy the benefits of free software for all of your programs not just a PDF reader.
Re: (Score:2)
> Jumping from one uninspectable, unmodifiable proprietary PDF reader to another is not wise.
I don't have the time, the knowledge, and the motivation to inspect and modify my PDF reader. Few people do.
> Pick a free software PDF reader for all of your computers so you can see what it will do, change it to meet your needs, and share your improvements with the community.
Keep in mind that the vast majority is not going to read the source code. 'You can read the source' is irrelevant 99% of the time; if I
Re:So, don't use Adobe Reader (Score:5, Informative)
'You can read the source' is irrelevant 99% of the time;
The point is that someone, other than the original author, can and most likely has.
Re: (Score:2)
If one has at least KDE shared libs installed, kpdf could be a nice full feature open source replacement. I know there are lots of different alternatives exist but I was amazed by the performance and display quality of kpdf on OS X (installed via fink). We already have state of art quartz pdf renderer and it is hard to impress people on this platform.
Adobe Reader is just the latest example. (Score:3, Insightful)
I'll bet you're right: there's simply too much source code in a modern-day free software OS for any one user to inspect it all, much less change it to suit their needs. But to jump from this perfectly reasonable conclusion to rejecting the freedoms of free software is illogical, ignores the lessons of history, and is therefore most unwise.
You're always better off with the freedoms of free software even if you don't leverage all of those freedoms yourself. This is one of the great differences between the "
DONT CROSS THE STREAMS (Score:4, Insightful)
Executable code should not be embedded in documents, the format should not allow it, and document readers should not execute code.
How fscking hard is this?
Re: (Score:2)
Executable code should not be embedded in documents, the format should not allow it, and document readers should not execute code.
Sorry, but you lost this fight a long time ago. Even emacs supports embedded executable code in documents.
Re:DONT CROSS THE STREAMS (Score:4, Interesting)
Sorry, but you lost this fight a long time ago. Even emacs supports embedded executable code in documents.
And don't forget Postscritpt. And LaTeX.
At the ICFP08 conference, there was a student who'd written an autonomous (simulated) robot controller, in LaTeX.
Re: (Score:2)
Re: (Score:3, Funny)
You mean, even LaTeX is not safe against Viruses? What should we use then?
LaMbSkIn?
Re: (Score:2)
Re: (Score:2)
Just let's hope that the bridge won't be a toll bridge when it'll be finished...
Re: (Score:2)
Writing documents with or without LaTeX is a different matter, because you always have to think about the health of your partner to whom you'll send your documents too. Of course, all this becomes moot if you only exchange documents with a single person (you'd only sent back viruses to where they came from in the first place), but after a while it'd be rather boring.
Re: (Score:2)
Re: (Score:2)
Just because you can put executable code in a document, doesn't mean the document reader should execute it.
Re: (Score:2)
Just because you can put executable code in a document, doesn't mean the document reader should execute it.
True, but at least with LaTeX and Postscript, some code must be executed just to render the document. So for some document formats, precluding all document code execution makes the rendering program useless.
Re: (Score:2)
No, the yutzes who allowed emacs to execute code lost the fight.
Re: (Score:3, Interesting)
No, the fight was lost when we first decided to use ones and zeros to represent both code and data. There is simply no significant difference between the two. Indeed, you can't have data which does not alter the execution of code.
Re: (Score:2)
Re: (Score:2)
And if you really, really have to allow some kind of code in documents, for the love of all that's holy, don't allow anything to execute by just hovering your mouse over it.
I don't know who to shout at more for this. Adobe for having such a stupid bug. Or Microsoft for allowing people to modify windows explorer in such an unsafe way.
If you're going to allow extensions to such a fundamental part of the OS, surely they should be sandboxed and isolated, to guard against exactly this kind of thing?
Re: (Score:2)
Remember WMF?
A graphics file format that basically relied on calling Windows primitive functions to draw itself and (for a long time) allowed arbitrary binary code inside them to be executed whenever they were displayed?
Code = OK, connect to outside = bad! (Score:4, Insightful)
Executable code should not be embedded in documents
Why not? Seriously, why not?
The real problem, IMNSHO, is not that there's code, but that the code is allowed to do other things than to just compute stuff.
I'm not really sure why you'd want documents to contain code, but I can imagine someone might want to say "the first 20 primes are 2, 3, ..." and have the computation done at "run"-time. Or at least, something else interesting that exceeds the capabilities of easily analyzable language classes (regular, context-free).
The badness happens when document-embedded code can read my file system, write to my file system, run other programs that are outside its own sandbox, or talk to others via the network.
(I think the Java security model tried to do approximately this.)
As a way to attack parts of the problem, perhaps document readers should just run the format interpretation code in a process which drops all unnecessary capabilities?
At least in principle, being able to compute doesn't mean being able to violate your security concerns.
In haskell terms, none of the code inside a document should have the type `IO a', and then you'd be safe (assuming of course that unsafePerformIO and the like didn't exist).
Re: (Score:3, Insightful)
How is a microkernel going to protect against a phenomenon that happens completely within userland?
Re: (Score:2)
Re: (Score:2)
By making practically everything into userland, including hardware drivers, filesystems, GUI's, etc. In most OS'es that's a lot of code, and there are bugs and vulnerabilities in there too, you know.
Maybe so, but not relevant to the original topic which was buffer overflows in user applications.
By enforcing strict limitations on what each part can do. In a common OS, malicious code can do everything a normal user can do. In a microkernel OS, that part may have no disk access rights whatsover, and only permission to communicate with a small number of other components. Such restrictions can be enforced strongly, and everywhere throughout the system. That makes breakage much more a local event, with limited damage.
That doesn't really have anything to do with the kernel architecture. You're talking about a capabilites-based system, and/or splitting user apps into groups of sandboxed subprocesses, both of which can be done with or without a micorkernel. What you want requires rewriting all end-user applications from scratch, but it could be done with only minor modifications to standard kernels.
Even Microsoft was able to in
PDF and Viruses (Score:2)
I caught my first ever virus using Firefox thanks to some sort of PDF exploit. Was browsing normally, got a popup that flashed up for a brief second and I saw it was a PDF of sorts. My hdd started thrashing and my anti-virus started giving me dozens of warnings.
Managed to make sure there was no trace of the virus on my system but it serves as a warning to people who assume Firefox is perfectly safe providing you are careful.
Re:PDF and Viruses (Score:4, Informative)
If you allowed a popup to occur you were not being careful.
Re: (Score:2)
Re: (Score:3, Informative)
Does it matter? GP could also have have been tricked to click a link that leads to the same page as the popup. Disallowing popups would not have saved him in that situation. The problem is not allowing popups, the problem is that his browser was not secure.
Re: (Score:2)
Re: (Score:2)
This type of exploit has been around for a while, actually.
I had certain common malware installed because a banner on a popular site carried a PDF that I didn't even have to click on.
Re: (Score:2)
Re: (Score:2)
You'd like to hope if you put unleaded petrol in a diesel car that it wouldn't explode in a huge fireball causing you a painful death.
Non-install alternative for Windows (Score:5, Insightful)
I stopped using Reader long ago - not because of vulnerabilities, but because it was so slow and bloated and it installed stuff I did not want.
I've been using Sumatra for a very long time and it has done well by me (http://blog.kowalczyk.info/software/sumatrapdf/index.html)
Download the zip file for a no-install, single-file exe. Minimalistic but more than enough for 90 percent of pdf's I ever need to open (the rest, I open through Google docs.)
Whoa (Score:5, Interesting)
So when I click once on a file, executable code is run from the program associated with that file?
When I view a file in Thumbnail mode, executable code is run from the program associated with that file?
When I hover to get a filename, executable code is run from the program associated with that file?
How many other daft, unnecessary executions of programs are there?
Not surprising because this is Windows we are talking about but holy crap - what a way to design a file browser / operating system. The problem here is NOT Adobe, or PDF or anything else, the problem is terminally-shit operating system and file browser design - executing entire programs to perform unnecessary tasks (e.g. add a column to explorer, generate a small bitmap, provide some hover-text). My next question is: in which user context is that code run? Please tell me that it is AT MOST the current user and not SYSTEM or some other built-in account. This sort of stuff should be found by a series of regexp's (which the program supplies) on the file data, NOT letting the program run just to tell you that Fred wrote this particular file. Then you can execute those to your heart's content in a secured area that benefits from global security upgrades if anyone finds a way to compromise the regexp. A bit like using "file" on *nix... just supply it with a regexp for a particular file extension and let the regexp extract the date, time, author, etc. in a safe environment.
No. Not MS. Every bit of freeware, every crappy game, anything that associates itself with a filename (which is almost impossible to stop on a home PC, only possible to detect/undo if you know how) is constantly run everything you view explorer in Thumbnail mode, or hover, or click on a file.
It reminds me of a little bit of trickery I did back in school... given the task to "hack the school network" on a computer course, we managed it within minutes by running exploit programs. Being the brightest IT student back then, I was asked to help prevent a repeat... my solution was to misuse the Windows 3.1 file associations in the global WIN.INI so that .exe, .com, .bat, .pif were associated with a tiny program that everyone had network access to. Anytime anyone ran a program, it was sent as a command-line parameter to this "security program" instead.
From there, the *program* would decide if the requested executable was actually valid and allowed (i.e. correct path, correct hash, put there by the network staff etc.) and if so, it executed it. If not, it popped up a message to deny access. It was surprisingly secure, given the state of multi-user networked Windows 3.1 back then, and even from an Administrator account we found it virtually impossible to get around provided other, more ordinary security was in place on WIN.INI (we even had to reset the admin account once because it managed to lock us out when we misconfigured it... fortunately, we had spare, unaffected accounts because we couldn't find any practical way around it!). Back then, though, you had to double-click, or File... Run... or whatever to make a program execute from the Windows shell... it even caught program execution from within Word macros that the network manager had been fighting for months ("A=Shell("Z:\game.exe")")... though not from a DOS shell, IIRC but we already had DOS Shells disabled by preventing the command.com from running except in specific contexts!
How easy it would be to write a piece of malicious code that associated itself with all executable file types and executed BEFORE the executable... so even when you try to run Remove_Sasser.exe or Install_Antivirus.exe, it would be intercepting and denying those requests. Obviously this has always been possible to do when somebody double-clicked on a executable, but now the associated program gets run just by LOOKING at any file with the right filetype. Make that executable a self-replicating virus and it's basically unstoppable (Yes, if you're
Re: (Score:3, Informative)
Not surprising because this is Windows we are talking about but holy crap - what a way to design a file browser / operating system. The problem here is NOT Adobe, or PDF or anything else, the problem is terminally-shit operating system and file browser design - executing entire programs to perform unnecessary tasks (e.g. add a column to explorer, generate a small bitmap, provide some hover-text).
That's strange, because the last time I booted up a Kubuntu live cd, the file explorer created preview bitmaps for all the PDFs in any folder I opened.
Re: (Score:3, Informative)
What did it use to create those previews? Adobe Acrobat Reader (the associated program for that particular user on that particular system) or a program that has been specified specifically for that purpose? Or even it's own internal renderer? I don't think it's sitting there loading up Acrobat Reader for Linux for every thumbnail, somehow, which is apparently what Windows does. I think you might find that konqueror internally decides to use libpoppler, no matter what file is associated with PDF mimetype
Re: (Score:2)
Granted it's not loading up Adobe Reader (at least, we both hope it isn't, because that would be immensely stupid). It's still linking in another library, which was essentially what you were ranting against. If the library is buggy, you could introduce security holes.
Re: (Score:2)
...and I don't know yea or nay, but the relevant question here is, does Konqueror allow installed applications to provide previews for "new" mimetypes? If the PDF preview library is "secure" and it's impossible to extend the preview feature to add libraries that preview new file types, then it's pretty secure. However, you've lost the flexibility of previewing new file types, probably unless someone updates Konqueror itself, since it doesn't trust your library.
Re: (Score:3, Informative)
Your +4 Interesting (at the time I'm writing this) rant against Microsoft completely fails to take into account the fact that this vulnerability is not limited to Windows, but in fact affects all platforms.
Now, please write your rant 100 times on the blackboard, substituting "Linux" for "Windows", then write it 100 times more substituting "OSX" for "Windows".
Re: (Score:2)
Actually, I'll think your find that *this* vulnerability affects only Adobe products but I haven't seen any mention of anything saying that non-Windows platforms are vulnerable... I just checked CVE, secunia, etc. and the only disassembly I can find of it is for Windows. I'm not saying that bug doesn't exist on other platforms, but that's not my point... my point is that it's executing a program with (at least) user privileges to draw an icon, or a tooltip. WHY?
I haven't seen another platform where Adobe
Re: (Score:3, Informative)
The Adobe advisory [adobe.com] indicates that it affects all platforms, and others in this thread have also pointed it out (some with links).
The second link [didierstevens.com] in the summary also explains that the preview functionality is added through a shell extension installed by Adobe, as opposed to default Windows functionality, although obviously Windows provides the API to make it possible. Similar functionality exists in the Linux and OSX worlds.
This is not the fault of bad Windows design. This is the fault of unnecessary preview
Re: (Score:2)
Yes, but do other operating systems use an Adobe shell extension to preview the file, or do they use an internal library? If you open the file with Adobe Reader, then sure, you're at risk. However, if the Adobe shell extension is opening the file to create the preview, you can execute the payload just by opening the folder containing the malicious PDF, whereas if a library that doesn't have this security flaw is used to preview the file, you'd have to actually open the file in Adobe Reader before it could d
Re: (Score:2)
Note that the preview functionality in OS X is provided by the system (which has an internal PDF implementation ... try opening the PDF in Preview), and the preview functionality in Linux is provided by a library.
Yes, it is the fault of bad Windows design, as well as bad application design. In OS X and Linux, the code that does PDF preview is extremely bare-bones without support for such 'features' as executable code. But it does the job.
The vulnerability is the result of a buffer overflow. You don't need executable code in the document to fall prey to it. In this particular case, it is easier to exploit the vulnerability if you use scripting in the PDF, but not necessary. Nevertheless, if this particular shell extension does happen to also execute scripts in the PDF, that's still not Microsoft's fault, since they didn't write the shell extension.
The libraries used by Linux and OSX are not immune to buffer overflows. If the libraries they u
Re: (Score:2)
Why? It's a trusted element of the operating system. Sandboxing it would be too much trouble.
Oh wait, a buffer overflow? Shit...
Hold on (Score:2, Funny)
Why all the paranoia about executable code (Score:4, Insightful)
One thing I don't understand is the seemingly common paranoia towards "executable code" in the discussions here.
First, there's no fundamental difference between "code" and "data". It's all binary blob. The .text section in any of your ELF programs is understood as "executable code" by the interpreter (ld.so) but as plain document by objdump. The point is to always interpret the data as how it is intended to be used, and this is hard. This Adobe fiasco is caused by a buffer overflow in the program (which is not even in a function responsible for JavaScript). Buffer overflows are known to be useful for exploits because they allow an attacker to "cheat" the program so that it misinterprets what intended to be document data as executable code. It just happens that the flawed code can be attacked with greater rate of success using JavaScript. (According to this security advisory http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20090219 [shadowserver.org])
Second, embedding executable code in a document is not inherently evil or stupid. It's just an idea that can be either utilized or abused, varying from implementation to implementation. I don't like scripting in PDF either but not for the reason of its alleged insecure nature, but because it bloats the file format.
Just my 2c..
Re: (Score:2)
One thing I don't understand is the seemingly common paranoia towards "executable code" in the discussions here.
TBH, I think you're more in agreement with them than you think - people are up in arms about executable code in documents *because* it's often so poorly implemented and the parsers have problems with it, resulting in vuln after vuln. I'm not against executable code in documents myself, per se - but I'm wary of anything that makes extensive use of it simply because it's been such a huge attack vect
Re: (Score:2)
First, there's no fundamental difference between "code" and "data". It's all binary blob
That's true on a von Neumann architecture. A Harvard architecture [wikipedia.org] CPU (used in some microcontrollers) has a stricter separation between the two concepts.
Curse you, von Neumann! (Score:2, Interesting)
I just don't get it. What exactly is so difficult about the concept of a file format containing data only, that is passively rendered by an application?
In fact, wasn't passive rendering the whole reason from moving from PostScript to PDF?
Is it that hard to review code and make sure that the interpretation of the format doesn't trigger any conditional branches that cause execution of anything but fixed, static, read-only code within the application? It seems to me you could use a modified version of one of t
Do you know a good software for PDF highlighting? (Score:2, Interesting)
Re: (Score:2)
Jarnal [dklevine.com]. It's a bit obtuse (you'll need to remove the default lined background, then open the PDF you're annotating as a background image – which does mean you can't edit the text, unfortunately), but then, it is free. It's done what I wanted, more or less.
If all you want to do is highlight (there are several pen tools which can be used to highlight or draw) or annotate (there's also a text tool, which as I mentioned can't edit the existing text in the PDF), it'll probably be adequate.
Re: (Score:2)
E-Copy.
It is not free, but it is an excellent work-flow tool (that uses PDF as the framework).
Great News (Score:2)
If they infect enough machines, perhaps something will finally be done about it.
Note to Adobe, you don't need SAP for this (Score:2)
As all companies in this economic disaster you will layoff people. I am sure you know which department to layoff and while on it, don't forget the OS X guys which manages to keep Debugger() symbols in World's most popular plugin, Flash.
Yes OS X people and especially Webkit/Browser developers, that mysterious ''Debugger() was called!'' in system.log comes from Flash 10 plugin because idiots forgot to remove debug symbols! That is a bug which wasn't fixed for months and even in recent security update release
Only 32-bit systems are vulnerable? (Score:2)
All typesetters must be interpreters (Score:2)
To all of those who don't think they want to see "executable code" in a PDF document....
How else would you implement a typesetting language? There is a big problem with simple bitmapped fonts, they don't scale, no sharp edges unless the scale of the bitmap exactly matches the screen resolution. So we need __instructions__ on how to draw the characters. Also those instructions change if the characters is large or small relative to the screen resolution. You can't make goos looking documents without some
I must have a special patched version. (Score:2)
I can't seep to find this 'Windows Explorer Shell' thing in aptitude or synaptic.
Re: (Score:3, Insightful)
Black hats don't read slashdot to fish for new exploits.
Re: (Score:2)
One thing I can add is that we have seen far worse examples of direct attempts at subverting and compromising user/consumer computer systems with their software products in the past. If we have seen worse, it's a lot less unreasonable to guess that this sort of thing is intentional.
Adobe PDF needs to be shunned in favor of open implementations just as MSIE is slowly being shunned in favor of Firefox.
Re: (Score:2, Informative)
Why in the world was this marked "Informative"??
The three exploits that Didier shows in his blog do NOT use javascript!!!
This "fix" won't work with these exploits.
Re: (Score:2)
Isn't Foxit free (as in beer) though?
Re: (Score:3, Informative)
Not '+1 Informative', this should be '+1 Misleading'. Disabling javascript is *not* sufficient to protect you against this exploit.
Re: (Score:2)
It was originally Javascript thing which could be fixed just by disabling javascript.
I think the person you replied to has good intentions and can't imagine the issue is that bad and fscking Adobe still wonders around without patching it.
If it was a government created such a security issue for a country, they would resign.
Re: (Score:3, Informative)
Not correct.
As to JavaScript, itâ(TM)s possible to exploit the /JBIG2Decode vulnerability without using JavaScript, and there are samples of this found in the wild.
—here. [didierstevens.com]
Re: (Score:2)
Not enough - if you click the file, and you have the Explorer status bar showing, it will call the PDF shell extension to fill the status bar details.
so you probably need to do something with this as well:
HKEY_CLASSES_ROOT\.pdf\ShellEx
Re: (Score:2)
TFA's author suggests [didierstevens.com]:
This is probably the easiest way: Nirsoft has a Shell Extension manager
http://www.nirsoft.net/utils/shexview.html [nirsoft.net]
Search for the PDF Shell Extension and disable it.