Slashdot Mirror
Adobe Flaw Heightens Risk of Malicious PDFs
snydeq writes "Security companies warn of a new flaw in version 9 of Adobe Reader and Acrobat that could compromise PCs merely by the opening of a malicious PDF. Although attacks are not yet widespread, hackers are exploiting the flaw in the wild, gaining control of computers via buffer overflow conditions triggered by the opening of specially crafted PDFs." Adobe is calling the flaw "critical" and says a patch for Reader 9 and Acrobat 9 will be released by March 11.
TFA doesn't mention whether or not Foxit is affected. If not, it's just one more reason to avoid the bloatware that is Reader.
...then I remembered that I use Sumatra PDF
Guess I'm going back to Adobe 5.1 again. And yes, I still have the install.
What would Richard Feynman do, if he were here right now? He'd do some math and he'd follow through!
And why exactly does Adobe Reader run with full permissions to all the user's files? Surely by now Adobe would have learned to run it in a sandbox. For example, the code that reads and renders the PDF could run in a separate process (a la IE8 or Google Chrome) and just send image data back to the main window.
More generally, the OS needs to make it completely easy to sandbox applications, so even the stupidest application developer can do it with little effort. Indeed, the default should be that it has no access to write files anywhere except those chosen by the user with the Save As box. I'm not holding my breath though...
-- Ed Avis ed@membled.com
Remind me why my digital document format needs JavaScript again?
I just tried to open a .pdf in Reader 9, and it's completely locked up - I've been stuck on the splash screen for 20 minu--
Oh wait, it's opened now. False alarm, sorry.
Meta will eat itself
Does that count as a patch?
The world is made by those who show up for the job.
Shadowserver wrote that the flaw could be exploited on systems running Microsoft's Windows XP SP3.
Yawn...
Why is it so hot? Where am I going? What am I doing in this handbasket?
Today is February 20. This is listed as a critical flaw and they are taking 18 days to release a patch. I'm glad they're getting right on this.
PDF has become what it set out to be, the de facto truly portable document format.
The problem is acrobat keeps larding in new features all the time to the point where in a corprorate environment you get more and more pdfs that require acrobat to even see.
it's an embrace and extend approach.
the problem here is the problem microsoft occasionally runs into-- if you monocrop then their is huge exposure to the possibility that viruses can spread like wild fire.
But with microsoft we were always in that boat from the first day they introduced it. microsoft docs always went hand in hand with the application software environment creating a stable ecosystem for any potential virus. (I use the term virus liberally)
with pdf this was not the case. Pdf is a format. there are many readers.
but adobe's constant racheting of add ons is threatening this.
Some drink at the fountain of knowledge. Others just gargle.
Nowadays I read my PDFs with Preview.
That's three weeks away! One week from now, pdfs are going to be on every questionable web page and email attachment. Step up the cycle, Adobe.
I'm using a non-Adobe PDF reader: Foxit Reader. It's commercial and not open source, but the non-Pro version is free to use; it's functionally far superior to the open source ones that were mentioned at Slashdot recently. I really hope the OSS projects can reach the level of sophistication of Foxit, because it's really my baseline of minimum PDF-reader functionality. The first OSS reader that can duplicate Foxit's sophistication will get a new convert.
"...Adobe is calling the flaw "critical" and says a patch for Reader 9 and Acrobat 9 will be released by March 11."
Boy, good thing they're getting right on this. Of course, perhaps a fix would be a little easier and faster if they didn't manage to take a simple PDF program and turn it into the obscene bloatware that Reader has become.
Great, I've got to wait 2-3 weeks for this to be patched.
Oh wait, Adobe have a 4 MONTH OLD bug that means we can't even run Acrobat 9 within our company:
http://www.adobe.com/go/kb404597
*seethes*
What's worse is that Autodesk hit this exact same bug with their beta of Design Review, and fixed it within a couple of weeks, so I know there's a fix for this.
Acrobat reader is precisely in the same position as IE4. Widely used and insecure. Users who are security conscious, vendor lock conscious, portability issues aware are the minority. Precisely the conditions that allowed Firefox to come, but the users in control once again, and take a healthy bite out of the market share of the dominant browser. Impact of Firefox is more than its marketshare. It forced web site developers to be aware of portability issues and become standards compliant. I am very sure other readers like FoxIt or something would take a big bite out of Adobe.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Time to nano all my pdf files, and read them in binary...
Does hardware Data Execution Prevention stop it from happening, in that this exploit would crash Reader instead of cause an exploit if DEP is enabled? I wish companies would suggest that as a possible mitigation, even if not all computers support it.
I did dumpbin /headers and saw that the EXE header for AcroRd32.exe has the "NX compatible" bit set. This means that DEP will be automatically enabled for Reader on Vista.
However, that doesn't cover XP. XP 32 SP3 has an API call named SetProcessDEPPolicy to request enabling DEP for your process. Adobe should modify Reader to call this function if it exists. (It exists on Vista SP1 as well, but Vista SP1 will already enable it due to /NXCOMPAT.)
XP 32 SP2 and XP 64 SP2, even though they have DEP, don't have a way to enable it if the system-wide DEP setting is "opt in" - the default. And there's no way to opt in that these support. (Google Chrome has code to use an undocumented system call to enable it, but it actually has no effect.)
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
It's not a bug, it's a feature!
View -> Page layout -> Show cover page during facing
Worked for me.
End of lesson. You may press the button.
I'm rather dismayed and horrified that operating systems don't already do this -- but then, reading TFA, I notice that "the flaw could be exploited on systems running Microsoft's Windows XP SP3", and suddenly it all makes sense, in a depressingly mediocre sort of way. The very concept that a reader program, for what are supposed to be static files, could pwn the whole OS is both flabbergasting, and par for the Microsoft course.
OTOH, TFA doesn't mention if this is remotely possible on Linux -- am I correct in thinking that Linux *does* sandbox applications at least a bit more effectively than Windows? Simply thinking through the cleaner division of administrative rights, I would think it does, but can anyone more knowledgeable about buffer overruns confirm that Linux is safer?
Curious,
"What in the name of Fats Waller is that?"
"A four-foot prune."
...I see what you did there. I still don't understand the appeal of those awful toolbars. They do nothing of consequence in my mind but sure do take up a lot of browser real estate. My girlfriend likes to run the google and yahoo toolbars together on her Vista machine*cringe*. Let me know when they come out with a toolbar with features worth giving up my browser space.
Bored at work? Play Game!
There's a saying about C: "We don't prvent you from doing stupid things because that would also prevent you from doing clever things."
There's also a saying about you: "A poor workman blames his tools."
Google Chrome leverages this Vista feature. http://dev.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ The sandboxing feature in Vista is implemented with process integrity levels. A process with "low integrity" is severely restricted in what it can do on the system. Adobe could use this feature for Acrobat. They actually do use it (they have to) for Flash, as the Flash plugin in IE runs inside the sandbox. The crux is that a sandbox is often so severely restricted that you need a helper (called "broker") process to do the privileged stuff such as downloading/uploading files etc. Flash actually made their own broker process for Flash and left a stupid bug in there. That was the flaw which allowed Vista to be compromised in last years' pwn2own contest.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
False.
Linux is safer in that software installs onto the root partition, where normal user accounts have read-only access. A buffer overrun could still be able to affect/modify data in a user's /home, though.
Want to hear the voice of GOD? cat
This is because interpreted JavaScript is regarded as data (to be read by the interpreter); NX is only effective against binary executable code.
Incidentally, this is a big difference between Java and .NET. Because Java typically uses hotspot VMs it will regard Java as data (byte code). Only if the hotspot compiler decides to compile the bytecode all the way to machine instructions will Java execute as binary code. Consequently Java will inherently be able to execute byte code. This means that for the processor the byte code is just data. If a buffer overflow can overwrite the bytecode or the Java stack, the interpreter is quite happy to keep on interpreting the bytecode.
.NET OTOH always compiles the IL (.NET bytecode) code to machine code before executing it. This means that the NX protection can actually protect .NET code but not Java code.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Comment removed based on user account deletion
The fact that the compromise of a PDF reader leads to compromise of the entire user account is a failure of the operating system, and Linux/Mac/BSD/Windows all fail equally here.
"Strangers have the best candy" -Me
It's all quite possible under Linux. Realistically, a number of protection mechanisms (many of which started being routinely used in Vista) should prevent buffer overflow attacks. Certainly they should prevent arbitrary code from making OS-level hacks -- which is probably why it only works on XP. While Linux also can use these mechanisms, the only sandboxing it does by default is user/administrator separation (like Vista does, and like XP doesn't generally do). To get OS-level access, you'd need a privilege-escalation attack, which are reasonably hard to come by for both Vista and Linux (and can be very hard to make reliable under Linux). Alternately, the attacker could just steal your data from the one running Acrobat Reader process he gets, which Linux won't do anything about.
Proper application sandboxing is certainly possible, but not easy. (Your PDF viewer, for example, should have read-only access to its own code, read-only access to a single PDF file, write-only access to screen space for drawing, and read-write access to scratch memory space. That's it.)
I've said it on here before and I'll say it again. Having access to the files or not there should not be a way in computers to inject code like this.
Shouldn't the no execute bit prevent this. Are we getting to the point where we should turn this on for everything. Can't Adobe ask windows
during the installation to add itself to the "I'm okay with DEP list".
Developers are going to make mistakes, I'm more mad that we still haven't fix the buffer overflow problem which to be is the core security flaw here...not Adobe.
Yes, let's go back to BCPL!
Disclaimer, this is an observation, but may seem a bit of a troll...
Once again we see market dominance and poor attention to security collide.
What makes this story interesting is the 'features' Adobe leaves enabled in PDF document features that even Microsoft knows better than to allow.
This creates the interesting aspect of Adobe losing touch and Microsoft actually getting it for once.
If you look at the MS XAML (XPS) document/display formats that compete directly with PDF, Microsoft got it right.
1) Less vulnerbilities - the lack of internal to external scripting of XAML and the sandbox nature of the XAML display and print formats dual sandbox the content inside a managed code environment.
2) XPS is void of scripting which more closely compares to PDF documents.
3) For print industry and press people, XPS/XAML is still turning heads even as new as it is compared to Postscript/PDF. This is not only in consistent print abilities, but speed as well.
4) Add all these together and then realize XAML/XPS can inherently draw and reproduce graphics that are outside the abilities of PDF and Adobe begins to have a reputation problem with companies like agfa, xerox, vari, etc.
(Yes PDF can display anything, but most advanced drawn graphics have to be rasterized because the language cannot inherently draw them. - This also increases the storage sizes and the processing times of high speed printers and presses.)
*A side note, because of OS X's dependence on Display PDF, it also has the same inherent drawing limitations when dealing with advanced graphics. Forcing applications to hack through the native drawing abilities of OS X, and in contrast developers on the Vista Windows side of the market are finding they no longer have to deal with limitations of GDI+ which is comparative to Display PDF on OS X.
Note: It is possible to exclude the Flash broker process from breaking through Protected Mode without a prompt, though it requires a registry hack.
There's no place I could be, since I've found Serenity...
It's because I'm burning up my employer's money reading Slashdot on an XP box! At home, it's Ubuntu through and through, I swear!
Well, except for Wine and VirtualBox.
Rich And Stupid is not so bad as Working For Rich And Stupid.
And a patch will be available on March 11? Boy, they sure are devoting all their resources toward getting a patch out.
Idiots.
Pax Vobiscum
That only leaves the question of why the heck that is not the default? And why you can't enable this option from within the Firefox plugin?
________
Entranced by anime since late summer 2001 and loving it ^_^
Here's a plug (from a satisfied user) for the open source but Mac-only Skim.
Skim is lightweight, fast, and scriptable. It allows for easy markup of PDFs either to the original file or separately. With Skim, one can convert annotations between its open format (written into the extended attributes) and Adobe's PDF standard. Combined with Apple's Preview.app, Skim can provides much of the functionality Adobe Acrobat.
blog
To an extent, yes. "Sandboxing" on a live system really encompasses a wide variety of potential ways that code can influence the rest of the system. (On the other hand, sandboxing with virtual machines is a much more straightforward problem.) One of these is access control. SELinux is an access control mechanism that provides more powerful and finer-grained access control than Unix's user model.
SELinux is a good example of how this sort of thing is tough to do. It can take a substantial amount of work for a user who knows how to use SELinux and knows exactly what his applications will need to access to impose those restrictions.
Uninstall Acrobat, the most bloated software product I've ever used.
The right way to approach this, as a matter of design, would be not to embed a Turing-complete language in a file format that doesn't need it.....You're comparing with a web browser. A web browser is qualitatively different
Actually, if you are going to be a purist about it, Javascript in a web browser is considered to be a security problem because it is a Turing machine. Active X, Flash, any sort of Turing machine in a web browser is always a client security problem and the safest way to deal with any of it is to block it. But users accept that the security risk is there, and now we have hoards of Russian botnets.
Society has spoken. End users are more interested in running code than they are either in anonymity and its time the internet change to reflect it. Security loopholes in any program are merely a reflection of the fact that the people choose features over the cost of having to be their own digital sheriffs, and its time to go hire real internet sheriffs, and go git those varmits.
This is my sig.
I didn't say that JS in a web browser wasn't a security problem. It is. I said that a browser was qualitatively different from a PDF viewer because a user wants and expects a web browser to run executable code, whereas a user doesn't want or expect a PDF viewer to do so.
In both cases, a security-conscious user can disable JS. (I use NoScript with Firefox.) The difference is that it's not reasonable to disable JS by default in a browser (because less sophisticated users will just notice that everything seems broken), and it's not reasonable to enable JS by default in a PDF viewer (because users don't want or need it).
Find free books.
Yahoo are like encylopedia salesmen. Or possibly drug pushers. Or possibly just horribly deluded that anyone would want their spyware^H^H^H^H^H^H^Htoolbar at all ?
You try to install Yahoo Messenger, "wanna toolbar ? uncheck box to NOT install it"
You sign up for a Yahoo Mail account, "wanna toolbar ? uncheck box to NOT install it"
You join a Yahoo Group, "wanna tollbar ? uncheck box to NOT install it"
Ad nauseum.
It would seem that Dictionary.com disagrees with you.
-verb (used with object)
5. to exert power or influence on.
6. to provide with leverage.
7. to invest or arrange (invested funds) using leverage.
Also Merriam-Webster Online
Main Entry: leverage
Function: transitive verb
Inflected Form(s): leveraged; leveraging
Date: 1957
1: to provide (as a corporation) or supplement (as money) with leverage ; also : to enhance as if by supplying with financial leverage
2: to use for gain : exploit <shamelessly leverage the system to their advantage -- Alexander Wolff>
Also Cambridge University Press Online
leverage (BORROWING)
verb [T] SPECIALIZED
to use borrowed money to buy a company
But I guess they're ALL ASSHOLES TOO EH ?????
Is there an attack for linux >?
Why do people, focus on Microsoft ? Is this going to hurt me in the next 24 hours, or don't you care ? I use Gnomes PDF viewer or Gnomes xPdf. (why does Firefoxs spellchecker complain about linux ?)
Are windows users in charge of the internet too ?
Yes, I know you blue, are doing the right thing, but the thread was drifting dangerously into cronyism. Surely we're all in this together ?
Fuck off.
Visual C++.
A c++ compiler will choke and die trying to compile that garbage. RIP little buddy.
Modding me -1 troll doesn't make me wrong.
Why is there Javascript in a document reader? Adobe holds the distinction as the only company that can write worse Windows software than Microsoft.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
I wouldn't steer people to a proprietary reader like foxit. If Adobe's PDF reader software were free software, we could fix it in any way we chose. The JS interpreter could be removed, or a less capable language interpreter could be put in, or a number of other changes could all compete for an audience. We could get the verifiable security one gets with Evince. By moving from one proprietary program to another, one merely moves from one master to another.
Digital Citizen
There is an option to disable javascript in the preferences. That would probably do the trick as well.
PDF form support isn't a particularly new feature; it goes back to at least PDF 1.3 (section 7.6 of the standard), published in 2000.
The feature which you describe--saving filled-in forms rather than detached form data--is supported as of evince 2.24.1 and poppler 0.8.7. It's quite standardized; you just fill in the 'V' key in the field dictionary, which is empty in a blank form. (See table 7.44 in the PDF 1.3 standard.)
Was that what you meant?
Laws do not persuade just because they threaten. --Seneca
Image if they got rid of all the SLOOOOW python in ubuntu would run considerably faster.
You don't actually know that. If you optimize without profiling things, you make a mess for yourself and don't actually improve anything.
Consider login time in GNOME. Your method would demand that gnome-settings-daemon be rewritten in assembler. Instead, consider that the login time was halved through careful profiling and algorithmic optimization--which is to say, nothing was rewritten in C.
As for slow performance of Python-based tools in general, note that the performance-critical libraries--cairo, GTK+, your video drivers--are all written in C. Rewriting the frontends isn't going to gain you much. If you disagree, go profile, and come back when you have more than simple kneejerking.
Heck, I just wrote a batch conversion process to move thousands of small XML files into one big XML file in another format. Time to execute xsltproc (in super-duper C!) a few hundred times for a test run? About a minute. Time to use a Perl interface to libxslt, along with parser hooks written as Perl subroutines? About four seconds, since I wasn't invoking xsltproc once for each input file.
Rewriting that project in C would have been time-consuming, error-prone, and utterly pointless.
Laws do not persuade just because they threaten. --Seneca