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.
The joy of patching all our machines. Sure we aren't going to just have to move to 10 and download the yahoo! toolbar to make that work?
...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...
Good alternative to Acrobat?
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!
It hit v3.0 recently and after all these versions it still doesn't support facing mode correctly. So when you have a magazine layouted for print it looks ridiculous on screen. Here's an example: http://www.dsu.dk/skakblad/sb2009/2009-01.pdf - it's in Danish, but just looking at the page layout (remember to put in Continuous-facing or facing mode) it should be obvious that it's wrong. This has been handled correctly in evince and kpdf for quite some time now.
________
Entranced by anime since late summer 2001 and loving it ^_^
When was the last time you heard about Pascal being used to make useful software, other than as a teaching language? That's not the greatest example you picked, as it has a lot of serious deficiencies. At least it's not Turing.
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."
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."
just because we've got cycles doesn't mean we should waste them. Image if they got rid of all the SLOOOOW python in ubuntu would run considerably faster.
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
But, but, Adobe Reader is written prodominently in C++, and contains no C....
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.
This problem was already solved in 1995. Not just was that when Java first appeared, but Visual Basic also didn't have this problem. I think if software contains a buffer overflow, the creators should be charged with criminal negligence or something, because they knowingly allowed a preventable security bug to happen.
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.
I reported this to Kaspersky weeks ago with payload. FWIW, e-mail exchange attached:
--snip--
Hello,
wdmaud.sys - Trojan.Win32.Agent2.agx
New malicious software was found in this file. It's detection will be included in the next update. Thank you for your help.
Please quote all when answering.
The answer is relevant to the latest bases from update sources.
>Hi,
>
>This is a variant of Win32/Daonol.B as identified by Microsoft. It is
>loaded in HKLM..\Drivers32 by modifying "aux" and hijacks Google
>search results, appearing to come from 7.7.7.0.
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 have noticed all sorts of weird pdf hacks happening, usually provoked by visiting torrent sites etc. I suggest installing the very light 6mb pdf reader fox-it, get it from download.com
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.
"leverages".
Oh really?
"Leverage" is a NOUN, not a verb...
Just because some business assholes decide to rewrite the language because they're too stupid to learn it properly, doesn't mean it has become officially changed...
Why didn't you write "Google Chrome USES this Vista feature"?
ASSHOLE!
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.
Skim is a reader that uses Apple's PDFKit and is so much better than Preview and Acrobat Reader that it is amazing. Faster, sensible, actively developed.
Think I had a close call with this yesterday. I went to one of the GCW mirrors (btw, some of these are booby-trapped with malware, others are perfectly clean, and if you don't know what GCW stands for I won't confirm or deny).
Anyway, went there with Firefox 3, lo and behold my Acrobat Reader opens up in the background. Firefox instantly goes to 100% cpu. I was able to kill both processes, with no apparent harm to my system. Malware scans come back clean. Nothing actually loaded in Acrobat, maybe because it's version 5, the last version that isn't chock full of bloat.
I also think FF3 going to 100% cpu is just a side effect of the same or different hack not working as it would have under IE.
I reported that particular mirror to the GCW admin. In the past they've actually been pretty responsive to these types of complaints. I once got a mirror removed for having those invisible click-anywhere ad links.
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
Why so serious? Let's put a smile on that face!
"A poor workman blames his tools."
True, but a good workman picks the right tool for the job.
I agree with the GP. C is used in far too many places where it does not belong. It is good for writing drivers, but that is it. If your application does not interface directly with the hardware, it should not be using C. Otherwise, you're just asking for a whole host of problems.
There is an option to disable javascript in the preferences. That would probably do the trick as well.
PISS OUT MY ASS!!!
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