×

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!

Adobe Acrobat JavaScript Execution Bug

ScuttleMonkey posted more than 7 years ago | from the oops dept.

Security 94

QASec.com writes to mention that Stefano Di Paola and Giorgio Fedon discovered an unpatched vulnerability in Adobe Acrobat Reader that can allow an attacker to execute arbitrary JavaScript on any hosted PDF file. People are reporting different results based on browser and Acrobat versions. Most of the major sites discussed have already fixed the problem, but many smaller sites may still need to be patched.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

94 comments

i see... (0, Offtopic)

User 956 (568564) | more than 7 years ago | (#17450310)

Adobe Acrobat JavaScript Execution Bug

So that's what happened to Saddam the other day... now it all makes sense.

Re:i see... (0)

Anonymous Coward | more than 7 years ago | (#17450786)

I'm still wondering how much Macromedia is paying the black-hats to keep Flash-exploits out of the wild. Some quite simple (layer 7) exploits are available for much less than EUR 5,000, yet you don't see them on the public forums.

Re:i see... (0)

Anonymous Coward | more than 7 years ago | (#17451918)

You're retarded, aren't you?

Common (2, Informative)

jrwr00 (1035020) | more than 7 years ago | (#17450382)

I sure have been seeing alot of javascript bugs lately,
http://it.slashdot.org/article.pl?sid=07/01/01/135 0219 [slashdot.org]

The whole architecture is fatally flawed (5, Insightful)

Anonymous Coward | more than 7 years ago | (#17450792)

Pardon me, but I am just sick of all this javascript nonsense. While the goal is notable, the design REALLY needs to be rethought and redone, from scratch. But this time with security in mind. It's quite clear that the original designers didn't have a clue about security. And the current batch, I'm sad to say, still doesn't take it seriously.

Yes, I know that those are strong words. But there has never been a secure implementation of anything where security was an afterthought, and bolted on later. Javascript is no exception.

Javascript has well shown that its approach can be very useful. But honestly, right now it seems almost as problematic as Microsoft Windows, when it comes to security issues. Frankly, the Open Source community really ought to be doing better here.

This is (IMHO) the biggest problem with the current implementation of all the Web 2.0/AJAX approaches. And until it's PROPERLY addressed, we're going to see a continual repeat of security issues, just like we see with MS Windows. It's not new; people have been saying this for years. And we still keep seeing these problems.

Pardon the rant, but I really do get tired of seeing this stuff when it should never have happened to begin with.

Re:The whole architecture is fatally flawed (3, Interesting)

abigor (540274) | more than 7 years ago | (#17451280)

It was addressed back in the '90s. It's called client-side Java. The VM was slow to start up (it still is), and it faced hostility from Microsoft. But security was an uppermost concern, and the whole architecture is pretty nice. Maybe if the start-up problems in the VM are addressed, client-side Java will return (it's wholly server-side now, except for a few standalone apps here and there) and we'll see an end to this silly Ajax stuff.

Re:The whole architecture is fatally flawed (0)

Anonymous Coward | more than 7 years ago | (#17451344)

I seem to remember about a billion security bulletins from Sun and patches and versions that wouldn't be patched. All that coupled with apps that would only work with 1.3.1 (which was unpatched) and apps that only work with 1.5, etc. No thanks! Java on the client didn't do so well because Sun made it a damn mess.

Re:The whole architecture is fatally flawed (2, Informative)

Thuktun (221615) | more than 7 years ago | (#17452092)

Client-side Java isn't necessarily any more secure, since it still has access to the hosting machine via the runtime libraries and JNI. Java *applets* are run in a sandbox, which limits what they can do and makes them more secure than a normal Java application. Perhaps that's what you meant to refer to.

However, to get full-page interaction of controls that you would get using Javascript, your applet would have to present the entire page itself, rather than being embedded in a page. In that respect, having declarative HTML controls with Javascript processes is more lightweight and scalable than using applets.

Plus, applets were architected to do asynchronous server-side requests separate from the main browser navigation, which is exactly what AJAX accomplishes for DHTML pages.

Re:The whole architecture is fatally flawed (1)

abigor (540274) | more than 7 years ago | (#17453002)

Yes, I thought it was implied that I was talking about applets, since the OP was ranting against Javascript. Sorry if that wasn't more clear.

Re:The whole architecture is fatally flawed (1)

Heembo (916647) | more than 7 years ago | (#17453026)

Java *applets* are run in a sandbox, which limits what they can do and makes them more secure than a normal Java application.

Although what you are saying here is true, one must weight the security history of applets in 2006 alone - take a look at my post below, I attached applet vulnerabilities that were posted days ago. Plus take a look at research from Marc Schoenefeld (awesome Java researcher) and Tom Hawtin (scarry smart Java cynic) http://jroller.com/page/tackline [jroller.com] - Java is NOT ready to enterprise prime-time, way way to many ways to escape the sandbox - and just not once or twice, but monthly applet vulnerabilities for the last several years. No thanks. I'm sticking to BSD, VI, Apache and LYNX only! :)

Re:The whole architecture is fatally flawed (3, Interesting)

Heembo (916647) | more than 7 years ago | (#17452976)

OMG you are smoking Java crack there boy. Client side Java has more vulnerabilities than... Javascript. I love Java, but keep it on the server where it belongs. MySpace is getting ready to consider migrating from .NET to Java, it's solid on the server. But on the client... nope.

Take this from the LAST sunsolve weekly report:

Newly Released Sun Alert Notifications

Sun Alert ID: 102729 (RESOLVED)
Synopsis: Security Vulnerabilities in the Java Runtime
                              Environment may Allow Untrusted Applets to Elevate
                              Privileges and Execute Arbitrary Code
Product: Java 2 Platform, Standard Edition
Category: Security
Date Released: 19-Dec-2006
Date Closed: 19-Dec-2006

To view this Sun Alert document please go to the following URL:
http://sunsolve.sun.com/search/document.do?assetke y=1-26-102729-1 [sun.com]

Sun Alert ID: 102731 (RESOLVED)
Synopsis: Security Vulnerabilities Related to Serialization
                              in the Java Runtime Environment may Allow Untrusted
                              Applets to Elevate Privileges
Product: Java 2 Platform, Standard Edition
Category: Security
Date Released: 19-Dec-2006
Date Closed: 19-Dec-2006

To view this Sun Alert document please go to the following URL:
http://sunsolve.sun.com/search/document.do?assetke y=1-26-102731-1 [sun.com]

Sun Alert ID: 102732 (RESOLVED)
Synopsis: Security Vulnerabilities in the Java Runtime
                              Environment may Allow an Untrusted Applet to Access
                              Data in Other Applets
Product: Java 2 Platform, Standard Edition
Category: Security
Date Released: 19-Dec-2006
Date Closed: 19-Dec-2006

To view this Sun Alert document please go to the following URL:
http://sunsolve.sun.com/search/document.do?assetke y=1-26-102732-1 [sun.com]

Re:The whole architecture is fatally flawed (1)

abigor (540274) | more than 7 years ago | (#17453032)

I never said there were no bugs. I said that the architecture had security in mind. Vulnerabilities like buffer overflows in the VM are a sad fact of life, and of course they'll have to be fixed. But at least the whole architecture isn't broken. Don't confuse architecture defects with coding bugs.

Re:The whole architecture is fatally flawed (1)

Heembo (916647) | more than 7 years ago | (#17453154)

With respect (this time) I submit that due to the long and consistent history of applet sandbox bugs in all vendors JVM's for the last many years, that the architecture for CLIENT side APPLET Java IS fatally flawed. You think corporate america is using Applets for highly secure enterprise applets? No way! Its fundamentally flawed when one call to System.setSecurityManager(null) totally wipes the entire sandbox for all applets running in a JVM.

Heck, they called setSecurityManager(null) a BUG for NOT WORKING back in 1997 and they FIXED it: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4034420 [sun.com]

With respect, keep away from Applets if you care about security.

Java got it wrong, too (1)

oohshiny (998054) | more than 7 years ago | (#17454072)

It was addressed back in the '90s. It's called client-side Java.

Not really; over the last decade, people have found numerous security holes, not only in Sun's implementation, but also in the underlying Java design.

Maybe if the start-up problems in the VM are addressed, client-side Java will return

I think J2SE is far too bloated for that. But J2ME/MIDP might make a good basis for reviving applets.

Re:The whole architecture is fatally flawed (0)

Anonymous Coward | more than 7 years ago | (#17451304)

It's not a javascript bug - its a pdf bug. As far as I'm concerned it's just one more reason to hate PDFs in browsers.

Re:The whole architecture is fatally flawed (0)

Anonymous Coward | more than 7 years ago | (#17452700)

No, it's fundamentally a javascript problem. While one can claim that it's a problem with PDF, if javascript had been architected better then it would be harder (if not impossible) to run across these types of problems.

Foxit? (2, Interesting)

phalse phace (454635) | more than 7 years ago | (#17450434)

Does this also affect Foxit reader, or is this just exclusive to Acrobat?

Re:Foxit? (0)

Anonymous Coward | more than 7 years ago | (#17450794)

No it does not affect Foxit.

Re:Foxit? (1)

slummy (887268) | more than 7 years ago | (#17450830)

Foxit is safe, I can't check the POC on my machine because I don't have Adobe installed. Anyone try Acrobat Linux yet?

Acrobat under Linux (1)

ArTourter (991396) | more than 7 years ago | (#17453052)

Yes Acrobat linux seems to be vulnerable to this and in this case we have no way to upgrade to version 8 as it is not available for linux yet. Switching off javascript in the preferences fixes the problem and fortunately, unlike under windows, the application doesn't come up with the message about the lack of javascript crippling functionality.

Re:Foxit? (0)

Anonymous Coward | more than 7 years ago | (#17450954)

No it doesn't. FoxIt Reader is the shiznit. I love it, and highly recommend using it.

Re:Foxit? (1)

afidel (530433) | more than 7 years ago | (#17453294)

FoxIt is definitely nice. In fact it's so nice I haven't even bothered to install Adobe's bloatware on my newest PC. Seriously thinking about buying a personal license to get to Firefox plugin.

Now we just need a Flash replacement (1)

Myria (562655) | more than 7 years ago | (#17455388)

I don't like Adobe and don't want any of their garbage on my system. GIMP is a "good enough" image editor for non-professionals, and FoxIt works great for PDFs. But there is no replacement for Flash, and too many web sites require it.

I installed my extra copy of Windows XP 32 in VMWare so that I could run Flash for GooTube videos. I won't run Adobe programs outside a sandbox.

Melissa

We have a Flash replacement (1)

maggard (5579) | more than 7 years ago | (#17503520)

But there is no replacement for Flash...
Sure there is, has been for years: SVG (look it up for yourself.) Does all of the same vectors & animation that Flash does, easier to create (its XML), and open. Its not even that hard to re-author material from Flash to SVG.

Quick assessment (5, Informative)

also-rr (980579) | more than 7 years ago | (#17450442)

The good: It can't remote root your webserver.
The bad: It can make your webserver appear to be hosting arbitrary content if you are hosting any PDF files and the user is using Acrobat reader.
The solution: Delete every PDF file hosted by your webserver OR configure your httpd to throw nasty errors for any requests that contain a string after the .pdf.

Something like this? (4, Informative)

cliveholloway (132299) | more than 7 years ago | (#17450966)

RewriteEngine On
RewriteRule /(.*?)\.pdf\?.*/ /$1.pdf [NC]
(untested)

Re:Something like this? (1)

Kalak (260968) | more than 7 years ago | (#17451020)

From reading the discussions, but not the paper, linked above, I was thinking the exact same thing. Seems kind of annoying to have mod_rewrite check all URLs for the server though, but it would should stop any servers with this from looking like a vector.

Can anyone see any holes in this logic? A practical use for anything after the .pdf extension?

Re:Something like this? (4, Informative)

brunascle (994197) | more than 7 years ago | (#17451028)

wont work. the javascript is after the #, so it's client-side. the server will never see it.

someone on sla.ckers.org [ckers.org] had a good suggestion: redirecting to a random, one-time address (that translates to the right PDF file on the server-side) if the client requests the PDF file directly. the valid addresses would have to be hard to guess, though.

Incorrect httpd Solution (2, Informative)

Anonymous Coward | more than 7 years ago | (#17451110)

The exploit works like this:

http://[URL]/[FILENAME].pdf#something=javascript:a lert(123);

Strings after # are not sent to the webserver. That is all client-side.

Re:Quick assessment (1)

a.d.trick (894813) | more than 7 years ago | (#17454520)

The bad: It can make your webserver appear to be hosting arbitrary content if you are hosting any PDF files and the user is using Acrobat reader.

Worse, much worse. It allows anyone to execute javascript code as if it was on your server. Another name for that is Cross Site Scripting. This can result in cookie stealing and many other nasty things.

More dangerous than it looks at first glance (1)

CTho9305 (264265) | more than 7 years ago | (#17455196)

You can be clever and read local files [ctho.ath.cx] of unwitting users...

Re:More dangerous than it looks at first glance (1)

TheLink (130905) | more than 7 years ago | (#17457380)

Doesn't seem to do much on my environment: Acrobat reader 4.0, IE6 (with active scripting off, active-x off, and set to download pdf instead of opening in browser).

OS X (1)

Yvan256 (722131) | more than 7 years ago | (#17450448)

Does this affect Preview on OS X too? After all, pratically all OS X users will use Preview to view PDF files (since Preview comes with OS X, and OS X itself has a PDF renderer built-in, at least from what I've read/understood).

Re:OS X (1)

UtucXul (658400) | more than 7 years ago | (#17450530)

Does this affect Preview on OS X too? After all, pratically all OS X users will use Preview to view PDF files (since Preview comes with OS X, and OS X itself has a PDF renderer built-in, at least from what I've read/understood).
I don't think this would affect Preview on OS X or xpdf since neither of them handle all the javascript that Acrobat Reader 6 and above can handle. I haven't used Preview much, so I could be wrong, but since I tend to use pdfs for slides for talks, and I embed movies using javascript (pdfanim and LaTeX), I have experimented with javascript abilities in the various viewers. I also just skimmed the linked page, so I could be totally wrong in everything I said. But I don't think so.

Let's be clear: bug is in Reader (5, Informative)

fractalus (322043) | more than 7 years ago | (#17450472)

The bug is that the Acrobat Reader runs the JavaScript.

Sites are "fixing" this by implementing work-arounds on the server to refuse serving the file if the script is tacked onto the URL. But these are kluges, stop-gap measures to reduce the damage until a proper patch can be made. The sites are not vulnerable; the reader is.

Re:Let's be clear: bug is in Reader (1)

PatPending (953482) | more than 7 years ago | (#17450762)

"bug is in Reader" Huh? TFA mentions the DOM. And a link from TFA had this follow-up: Works on:
Firefox 2.0.0.1 win32
Firefox 1.5.0.8 win32
Opera 8.5.4 build 770 win32
Opera 9.10.8679 win32
But doesn't work here on IE6 or IE7.
My Firefox was updated this a.m. to 1.5.0.9 and it was not affected. The Reader remains the same. BTW, I wonder how much credit the IE7 team gets for not being affected by this?

Make that the Reader Plugin (4, Informative)

Kelson (129150) | more than 7 years ago | (#17451364)

Remember, IE uses an ActiveX interface to load Acrobat Reader, while Firefox and Opera use the Netscape-style plugin interface. If the plugin interface is vulnerable, but the ActiveX interface is not, that would explain why it works with Firefox and Opera but not IE.

Also, as others have pointed out, Adobe Reader 8 appears to not be affected.

Re:Let's be clear: bug is in Reader (2, Interesting)

trianglman (1024223) | more than 7 years ago | (#17451498)

From what I have been reading on this it is a bug in how the browser and the reader integrate, not just with the browser and not just with the reader. And I agree, it pains me to say it but it seems that IE handles this correctly (tested myself just to be sure), but I do have to wonder why.

Re:Let's be clear: bug is in Reader (1)

brunascle (994197) | more than 7 years ago | (#17450866)

how can the sites fix this? the javascript part of the url is after the #, which doesnt get sent to the server.

Re:Let's be clear: bug is in Reader (1)

pe1chl (90186) | more than 7 years ago | (#17451486)

That depends. It looks like at least some browsers send the # to the server when it is part of a parameter, not something that looks like a pathname.

On our website we have a directory with .pdf files. On the site there are two kinds of links to it:

1. of the form /directory/filename.pdf which return the content as application/pdf which normally results in an embedded reader window. intended to view the document.

2. of the form /directory?file=filename.pdf which is handled by an index.php in the directory that processes the ?file= arg (ofcourse checking that it does not try to refer a file outside of the directory) and sends the file with a Content-disposition: attachment; filename="filename.pdf" header, which normally results in a popup to save the file.

Now I have found that sometimes we get references to URL of the form /directory?file=filename.pdf#search='searchkeyword '
It turns out that this happens when the user has selected that second form (which is intended for downloading the pdf rather than viewing it), then still selected it to be "opened by the application" from the browser save-file popup, and then performed a search operation inside the reader.
I found this a rather interesting form of information leakage, as you can see what search terms the users are using on your pdf... it must be intentional.

Maybe in this case that particular behaviour can be used by having URL of the form /directory?file=filename.pdf and the index.php (or .pl or whatever scripting language you like) sending just the mime type and the file, not the content disposition.
Disadvantage of course is that the reader cannot load partial data as it normally does when it is reading from a file.

Re:Let's be clear: bug is in Reader (1)

Schraegstrichpunkt (931443) | more than 7 years ago | (#17455362)

IIRC, the fragment part of the URL shows up in a Referer header, but it shouldn't be in the GET or POST request URI (but, interestingly, Apache seems to tolerate it).

Re:Let's be clear: bug is in Reader (1)

pe1chl (90186) | more than 7 years ago | (#17455608)

So one can consider that another bug in the reader. It seems to work OK when it is working from a simple pathname (I have never seen GET /directory/filename.pdf#search='keyword'), but when it is reading from a script with parameter(s), it will just pass on the # probably thinking it is part of a parameter value.

Re:Let's be clear: bug is in Reader (1, Informative)

Anonymous Coward | more than 7 years ago | (#17452318)

This kind of thing is why I disable Javascript, along with all the other crap that Adobe like to enable by default, the instant I install Reader (which, unfortunately, I must do from time-to-time). In versions of Reader prior to 8 it was difficult to truly expunge Javascript since, at least under OS X, a message would appear when you closed Reader saying something to the effect of "this document contains javascripts that are vitally important to the functioning of reader -- would you like to turn Javascript on so that the grass is greener and the air smells sweeter? Yes, please make the world a happy wonderful place. No, continue trying to hobble through life with crippled Reader functionality." Or something like that, every time you quit Reader or until you finally relented and re-enabled Javascript.

The solution for Reader 7 was to completely kill off Javascript by deleting a Javascript settings file then create a symlink to /dev/null with the missing file's name:

rm ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/glob.settings.js
ln -s /dev/null ~/Library/Acrobat\ User\ Data/7.0/JavaScripts/glob.settings.js

This was a bit brutal, but worked pretty well. Reader 8 no longer effectively requires Javascript the way way 6 and 7 did. You can simply disable it, along with "features" like allowing PDFs to launch external files, run movies, and other opportunities for mischief, right from within the preferences. No symlinks to /dev/null required.

Probably Acrobat 8 is safe? (5, Informative)

dawnsnow (8077) | more than 7 years ago | (#17450488)

I'm using Acrobat 8 and Firefox 2, and the acrobat plugin displays "This operation is not allowed" when I clicked the pdf link with javascript. Maybe everyone should upgrade their Acrobat reader.

Re:Probably Acrobat 8 is safe? (5, Insightful)

origamy (807009) | more than 7 years ago | (#17450646)

People *would* upgrade their Acrobat Reader, if they hadn't turned off that horrendous update screen that pops up every single time you open a PDF file.
Adobe could surely learn how to make a more user friendly "update is available" screen, kinda like Firefox does.

Re:Probably Acrobat 8 is safe? (1)

antdude (79039) | more than 7 years ago | (#17451924)

I am sure it was designed that way to annoy users to upgrade. :(

Re:Probably Acrobat 8 is safe? (1)

jeffstar (134407) | more than 7 years ago | (#17454508)

I select Win95 as my OS and download adobe reader 5.05 because it doesn't have that annoying popup
I don't know what the reader is on ubuntu, whatever comes up seems to do the trick

Re:Probably Acrobat 8 is safe? (1)

owlstead (636356) | more than 7 years ago | (#17452778)

And not crash. And only load plugins when needed. And not mess with the status bar. And would use close buttons on the title bar like they should be used. And not mess up firefox. And not save PDF files on the temp folder by default. And copy correctly. And not enforce uninforcable anti copying protection. And have a reasonable search method. And use the pointer like it should be. And have normal scrolling behaviour. And not use weird keyboard shortcuts. And have bookmarks etc.

I probably am still missing a few gripes. Since I just want it to display PDF files, I use foxit reader, which seems to get it right.

Re:Probably Acrobat 8 is safe? (1)

mritunjai (518932) | more than 7 years ago | (#17450988)

Seconded! Exploit doesn't work with Reader 8

Same result with Adobe Acrobat Reader 8 with Opera 9.10.

Re:Probably Acrobat 8 is safe? (1)

Matt Perry (793115) | more than 7 years ago | (#17452564)

I'm using Acrobat 6 and Firefox 2. PDFs open fine and I don't see any abnormal behavior when clicking on the POC link.

What, no Phil Dick reference from ScuttleMonkey? (0, Offtopic)

Cr0w T. Trollbot (848674) | more than 7 years ago | (#17450522)

After Do Electric Sheep Dream of Civil Rights? and A Shopping-Scanner Darkly, I was hoping for another Philip K. Dick title reference from ScuttleMonkey here. "'Squash My JavaScript Bugs,' the Acrobat said", perhaps? The Acrobat Whose JavaScript Bugs Were All Exactly Alike? JavaScript Bugs of the Acrobat Moon?

Crow T. Trollbot

Re:What, no Phil Dick reference from ScuttleMonkey (-1)

Anonymous Coward | more than 7 years ago | (#17451186)

If you would "phil" your dick less often you'd have noticed that this shit is off-topic.

Work around? (5, Funny)

Anonymous Coward | more than 7 years ago | (#17450546)

It's typical that they don't mention any work around. I'll be the first to put one up; first open up a command prompt then run

  chmod -x `which acrobat`
  rpm --erase acrobat
  rpm --install xpdf

there, couldn't be simpler. If you find these commands don't work on your system, you either need to use the "apt" command instead of "rpm" or upgrade your operating system. If you are running OpenBSD and you've managed to install and run acrobat then you don't need my instructions.

The problem with that (1)

MillionthMonkey (240664) | more than 7 years ago | (#17451162)

If you ever do decide you want Acrobat again, you'll have to run the Adobe Acrobat Reader 7.0 installer. And then four more installers to climb up the versions from 7.0.1 through 7.0.8 or whatever it is now. And then the final installer to fix this vulnerability.

Or you can find the 5.0 version somewhere, from happier days. Somebody at Adobe really has their head up their ass.

Re:The problem with that (1)

MillionthMonkey (240664) | more than 7 years ago | (#17451260)

Oops, wrong OS, duh. I read that too fast.

Actually is Adobe's reader any better on Linux, or is the crappiness specific to the Windows version?

Re:The problem with that (1)

Schraegstrichpunkt (931443) | more than 7 years ago | (#17455372)

I haven't seen the Netopsystems FEAD Optimizer on Linux...

But acroread is still pretty slow and bloated compared to xpdf. It has a few more features (like filling in PDF forms), but I need those features so rarely that I could really just install acroread when I need it, and uninstall it when I'm done.

Using acroread to view PDFs on Linux is a mistake, generally speaking.

Re:Work around? (0)

Anonymous Coward | more than 7 years ago | (#17451510)

you forgot:
ln `which xpdf` /usr/bin/acrobat

Novell/SuSE (0)

Anonymous Coward | more than 7 years ago | (#17457836)

Novell/SuSe, as always, was the first to remove xpdf in favor of Acrobat Reader (there is *More* to acrobat than the reader ;)), which is closed source, but luckily you can't go ahead and accidentially print PDFs with the no-print bit set. Phew.

And at about the same time, Novell/SuSE started running portable dot Net from the init scripts and "Registering IL executables". While Mono was funded.

Need more proof to understand that Novell is dead for the linux community?

Nothing happens under Vista with Acrobat 8... (1)

MSFanBoi2 (930319) | more than 7 years ago | (#17450632)

Nothing at all happens (other than the PDF opening)... so Vista and Acrobat 8 seem immune.

Re:Nothing happens under Vista with Acrobat 8... (1)

phalse phace (454635) | more than 7 years ago | (#17450746)

Did I read that correctly? Vista is immune, as in Windows Vista?

[/shocked]

Wait, wait, wait (1)

porkchop_d_clown (39923) | more than 7 years ago | (#17450642)

Why did these villains publicize an unpatched exploit? Why didn't they go through normal channels [slashdot.org]?

I question the timing [slashdot.org]. What are they trying to prove, by doing this? They must be trying to profit from it [slashdot.org].

Oh, wait, this is about Adobe and not Apple. Nevermind.

This is a client side problem (0)

Anonymous Coward | more than 7 years ago | (#17450834)

>Most of the major sites discussed have already fixed the problem,
>but many smaller sites may still need to be >patched.

This is a client side problem. The worst part is... that the part of the URL after the hash is never sent to the server (which in what holds the malicious code) so there is little that can be done on the server side.

One possible work around on the server side:
Direct your web server to serve .pdf files as mime type "application/octet"
That way the files will be saved to disk instead of opening in the browser plug in.

Re:This is a client side problem (1)

Kelson (129150) | more than 7 years ago | (#17451440)

One possible work around on the server side: Direct your web server to serve .pdf files as mime type "application/octet"

Most people in a position to implement that idea probably know this already, but for those who aren't, the typical MIME-type for generic downloads is "application/octet-stream".

Re:This is a client side problem (0)

Anonymous Coward | more than 7 years ago | (#17456056)

The only problem with that solution is IE/Opera. Both will either sniff the content or guess based on extension and open with the plugin. Serving PDFs with an unknown MIME type like application/x-not-a-pdf will take care of Opera (and degrade nicely for clients that properly respect application/octet-stream), but IE needs a Content-disposition: attachment header to make it stop trying to be 'helpful'.

What the hell? (1, Funny)

Anonymous Coward | more than 7 years ago | (#17450888)

What the fuck is with this bullshit that posting ANONYMOUSLY still cancels out any moderations you have made? Oh, and better still, those points are wasted forever instead of being given back to you (which is what "Undone" like it fucking says would imply).

Re:What the hell? (1)

pclminion (145572) | more than 7 years ago | (#17451258)

Dude... You have to LOG OUT and THEN post anonymously.

As for why the points aren't given back to you... It prevents the typical abuse where some idiot moderates a stupid post, then waits a few minutes to let other idiot moderators see it. Moderators typically moderate up posts which have already been modded up. So you wait until everyone else pushes your target post up to '5', then you post a comment which undoes your moderation. So you keep your mod points but you can control which posts get modded up. The solution to the stupidity is to not give you back your mod point.

Re:What the hell? (1)

Kelson (129150) | more than 7 years ago | (#17452006)

Dude... You have to LOG OUT and THEN post anonymously.

Another option is to keep a second browser around that's not logged in.

Re:What the hell? (1)

afidel (530433) | more than 7 years ago | (#17453384)

Actually neither works with current Slashcode, if a post is made from the same IP (possibly in a set period of time, haven't dug into it) then the moderation is removed. Sucks if you are at a big company with a proxy server, but it prevents the anonymous abuse hole you are talking about.

Re:What the hell? (1)

makomk (752139) | more than 7 years ago | (#17466474)

Actually neither works with current Slashcode, if a post is made from the same IP (possibly in a set period of time, haven't dug into it) then the moderation is removed. Sucks if you are at a big company with a proxy server, but it prevents the anonymous abuse hole you are talking about.

So let me get this straight... if anyone in my university halls posts to a Slashdot thread within a certain timespan of me moderating it, my moderation will be silently undone? (There's a *really* nasty NAT setup there...)

Re:What the hell? (1)

afidel (530433) | more than 7 years ago | (#17472106)

Correct. The first time I thought it was a cookie or something, so I posted anonymously from my wife's pc which never goes to slashdot but which sits behind my nat'ing router, and my moderation still went poof.

sla.ckers.org (1)

id (11164) | more than 7 years ago | (#17450924)

This also being discussed at sla.ckers.org [ckers.org] along with a useful suggestion for keeping yourself safe from a lot of these type vulnerabilities.

I don't like PDF (5, Interesting)

LiquidCoooled (634315) | more than 7 years ago | (#17450946)

I recently signed up for the "send your name to wherever" thing pointed out on slash (its in my comment history somewhere)
The PDF was formed with parameters linking to a second pdf base document.

From Firefox on Windows with internet explorer disabled the pdf opened inside acrobat then proceeded to display the resulting PDF file in internet explorer.

I haven't seen IE now for ages and that made me nervous as hell.

Re:I don't like PDF (1)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#17451444)

From Firefox on Windows with internet explorer disabled the pdf opened inside acrobat then proceeded to display the resulting PDF file in internet explorer.

It sounds like your problem is with Acrobat Reader, Windows, and IE. Acrobat shouldn't launch a non-default browser and Windows should allow you to disable or remove IE. For that matter, IE should not be bundled in the first place, so that developers don't rely upon it being there and develop their applications to be browser independent.

PDF itself is just a format, and a nice one. Since I would never browse general Web sites with Windows, let alone with acrobat installed, I don't have to worry about that problem.

Re:I don't like PDF (1)

MMC Monster (602931) | more than 7 years ago | (#17452566)

If IE is not bundled with the OS, how is the average user supposed to download firefox? It's been years since I used ftp to download pretty much anything.

Re:I don't like PDF (1)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#17452614)

If IE is not bundled with the OS, how is the average user supposed to download firefox?

Using whatever browser the OEM includes: Firefox, IE, Opera, or whatever. The point being since it doesn't come with Windows developers can't assume it will be there and make stupid design decisions based upon that.

Re:I don't like PDF (1)

cdrguru (88047) | more than 7 years ago | (#17452880)

Sorry, IE is here to stay in Windows. Why? Because they dropped WinHelp and created the replacement as HTMLHelp. Can't render HTML without a browser, therefore you can't display help for the OS without IE.

Re:I don't like PDF (1)

whitehatlurker (867714) | more than 7 years ago | (#17452888)

Acrobat shouldn't launch a non-default browser and Windows should allow you to disable or remove IE.

I agree that the default browser should be used, but until I updated to acroread 8, Acrobat would open links in IE. (Swore like heck whenever it happened to me.) It seems to be fixed now, and stuff opens in Opera, like the computer god (or, well, at least me) intends.

Hope you get the "funny" mods for your second point.

Actually there is no site patch (0)

Anonymous Coward | more than 7 years ago | (#17451066)

There is no way to patch this on the server side since this is a client side vuln in adobe reader. BTW I posted this story and never said that :)

Firefox extension anyone? (1)

140Mandak262Jamuna (970587) | more than 7 years ago | (#17451098)

Would someone please write a quick Extention to Firefox to chop truncate links to pdf documents to remove the #some_string=javascript:spoofed_script

Please?

I should find where I had saved the firefox extension development SDK and learn it.

Firefox extensions are themselves a problem. (1)

argent (18001) | more than 7 years ago | (#17453820)

Or rather, the way you install them is.

The main difference between this and a Firefox Extension is the Firefox makes you wait a few seconds and then click on the "I want to do something really stupid" button. Adobe figures that most people don't care, and presses the "I want to do something really stupid" button FOR you.

My experience as a system administrator is that the only way to get people to quit pushing the "I want to do something really stupid" button, is to make it more inconvenient to jump through the hoops and push the button than to download the file and launch it from the desktop or shell.

Firefox is nearly there.

Shrug... (0)

Anonymous Coward | more than 7 years ago | (#17451318)

Given how bloated Acrobat Reader had become, I had already stripped out half the plug-ins and disabled Javascript within Reader anyway. It is rarely used and it was an obvious accident waiting to happen, security wise.

JavaScript error (1)

zakeria (1031430) | more than 7 years ago | (#17451448)

We should all be safe then considering nobody seems to know how to script in javascript

Re:JavaScript error (0)

Anonymous Coward | more than 7 years ago | (#17455218)

We should all be safe then considering nobody seems to know how to script in javascript
Won't somebody please think of the kiddies!

</kneejerkresponse>

Also to be called the 3rd Month of Apple Bug? (1)

Vandil X (636030) | more than 7 years ago | (#17452174)

They may as well, seeing as they've posted no real Apple bugs to date.

FIle Under, "Duh" (4, Insightful)

ewhac (5844) | more than 7 years ago | (#17452640)

It was inevitable this would happen ever since Adobe made the impossibly stupid move of adding JavaScript to their reader. Really, I can't heap enough well-deserved derision on this boneheaded, lame-brained, imbecilic, preposterous, self-serving, idiotic, fucktarded idea.

Every time I install Acrobat Reader, I dive through the preferences panel and fix all the incorrect defaults. One of the things I turn off, and which should be off by default, is JavaScript execution. Whether turning this off will protect against the described vulnerability, I don't know, but it's probably a reasonable first line of defense.

A lot of the factory-default settings in Acrobat Reader are (stupidly) wrong. You should review all of them.

Schwab

Re:FIle Under, "Duh" (0)

Anonymous Coward | more than 7 years ago | (#17453982)

It was inevitable this would happen ever since Adobe made the impossibly stupid move of adding JavaScript to their reader. Really, I can't heap enough well-deserved derision on this boneheaded, lame-brained, imbecilic, preposterous, self-serving, idiotic, fucktarded idea.

Do you complain this much about javascript in HTML? After all the web was around and working before javascript.

Would you prefer a proprietary language that only for use in Adobe products? I think they did the right thing and opened up making dynamic PDF files with a standard language.

JS in PDFs is really handy for offering field validation. Also you can import AutoCAD documents and make them dynamic.

Re:FIle Under, "Duh" (1)

ewhac (5844) | more than 7 years ago | (#17454100)

Do you complain this much about javascript in HTML?

Yes.

JavaScript was an amazingly stupid idea there, too, because it takes what was originally supposed to be a document (i.e. a static presentation of information) and turns it into software, with all the attendant hazards. I keep JavaScript turned off by default.

The macro viruses that plagued Microsoft Word showed exactly what kind of trouble would inevitably follow if you turned documents into software, but tried to pretend they were still "documents". But apparently no one was willing to learn that lesson. So now we're stuck with JavaScript, pop-up ads, pop-under ads, auto-playing music, and a host of other garbage. Now Adobe seems intent on doing the same thing to PDFs.

Schwab

Re:FIle Under, "Duh" (0)

Anonymous Coward | more than 7 years ago | (#17457988)

Whether turning this off will protect against the described vulnerability, I don't know, but it's probably a reasonable first line of defense.
A comment I read on one of the linked blogs suggests that this is not the case -- implying that the URL javascript executes even if the javascript option is turned off inside of Acrobat. Haven't checked this myself, though.

More info? (1)

julesh (229690) | more than 7 years ago | (#17455710)

There's a lot of missing information here.

1. What context does the js execute in? Browser or Acrobat? If Acrobat, does it have access to your cookies? (I'd guess not)
2. What versions/browsers are affected? I'm using FF2 with Acrobat 5, and nothing seems to happen, but this could be because I've got an odd setup.

Anyone know?
Check for New 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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...