Beta
×

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!

Ask Slashdot: How Do You Automatically Sanitize PDF Email Attachments?

samzenpus posted about a year ago | from the get-to-scrubbing dept.

Security 238

First time accepted submitter supachupa writes "It seems the past couple of years that spearfishing is getting very convincing and it is becoming more and more likely someone (including myself) will accidentally click on a PDF attachment with malicious javascript embedded. It would be impossible to block PDFs as they are required for business. We do disable javascript on Adobe reader, but I would sleep a lot better knowing the code is removed completely. I have looked high and low but could not find a cheap out of the box solution or a 'how to' guide for automatically neutralizing PDFs by stripping out the javascript. The closest thing I could find is using PDF2PS and then reversing the process with PS2PDF. Does anyone know of a solution for this that is not too complex, works preferably at the SMTP relay, and can work with ZIPed PDFs as well, or have some common sense advice for dealing with this so that once its in place, there is no further action required by myself or by users."

cancel ×

238 comments

Sorry! There are no comments related to the filter you selected.

Butts (-1, Troll)

Anonymous Coward | about a year ago | (#44314141)

Stick it in your butt.

Foxit Reader? (5, Informative)

Anonymous Coward | about a year ago | (#44314153)

As far as I know, Foxit Reader strips out any JavaScript. The PDF readers in Chrome and Firefox also should do the same.

Re:Foxit Reader? (3, Informative)

MoFoQ (584566) | about a year ago | (#44314167)

dang...I was about to say the same...

but yea...best way to sanitize is by not using Adobe Acrobat (or Acrobat Reader).

on OSX and many Linux distros have their own builtin viewer ("Preview" in OSX, and "Display" at least on Ubuntu).

Also, you can probably use Google Apps to do the same as well.

Re:Foxit Reader? (5, Insightful)

fuzzyfuzzyfungus (1223518) | about a year ago | (#44314533)

That isn't really 'sanitizing', though: It's certainly good that you practice safe text on your computer; but if you are the mailserver guy, and may or may not have as much control as you'd like over the users and their filthy, weatherbug-encrusted, systems, you want to modify the file such that it no longer contains a potential payload, not merely use a reader that doesn't execute payloads.

Re:Foxit Reader? (1)

Anonymous Coward | about a year ago | (#44314577)

weatherbug my god... that fucking thing is on everyone's computer now.. WHY? How does a simple application that polls maybe a few hundred bytes of information take so much fucking cpu? IT"S IMPOSSBLE!

Re:Foxit Reader? (2)

king neckbeard (1801738) | about a year ago | (#44314655)

perhaps you could sanitize their systems by preventing them from running Adobe products.

Re:Foxit Reader? (1, Flamebait)

Anachragnome (1008495) | about a year ago | (#44314647)

"Also, you can probably use Google Apps to do the same as well."

You aren't seriously suggesting using Google to address a security issue, are you?

Re:Foxit Reader? (1)

Anonymous Coward | about a year ago | (#44314945)

Why not?

If you're on a Microsoft OS, it doesn't matter what else you do, your computer is pre-compromised.

If you're not on Microsoft, Google Apps runs in a web browser context and has all the protections of the browser.

Re:Foxit Reader? (0)

Anonymous Coward | about a year ago | (#44314877)

Print them out, then spray them with a solution of Vioxx?

Re:Foxit Reader? (2)

thelukester (2722207) | about a year ago | (#44315021)

Nitro and foxit now display JavaScript. You can disable it in options. Unless you want to use old versions, your best bet is sumantraPDF.

Tried and True (0, Offtopic)

oldhack (1037484) | about a year ago | (#44314155)

Can't go wrong with chicken bone.

Print to PDF (4, Informative)

digitalhermit (113459) | about a year ago | (#44314169)

The way I'd do it is to create a dummy printer driver that just writes to a file. Print the PDF to the dummy printer, which in turn creates a new PDF without all the junk.

Re:Print to PDF (0)

Anonymous Coward | about a year ago | (#44314223)

The way I'd do it is to create a dummy printer driver that just writes to a file. Print the PDF to the dummy printer, which in turn creates a new PDF without all the junk.

But don't you need to open it (thus potentially triggering javascript) to send the PDF to the printer? Under windows, at least. In Linux you could presumably just copy/pipe the file to the printer device?

Re:Print to PDF (2)

Em Adespoton (792954) | about a year ago | (#44314313)

The way I'd do it is to create a dummy printer driver that just writes to a file. Print the PDF to the dummy printer, which in turn creates a new PDF without all the junk.

But don't you need to open it (thus potentially triggering javascript) to send the PDF to the printer? Under windows, at least. In Linux you could presumably just copy/pipe the file to the printer device?

Do it via a service like Google Docs... ...At least it won't be infecting YOUR system.

Re:Print to PDF (4, Informative)

Kludge (13653) | about a year ago | (#44314245)

Like
lpr -P Cups-PDF file.pdf

Re:Print to PDF (5, Interesting)

DJ Jones (997846) | about a year ago | (#44314453)

Sadly a lot of PDF printers will retain javascript code even if you print it and re-assemble it back into a PDF. The problem lies in the fact that Adobe allows javascript to be embedded inside image objects and compressed blocks of PDF binary. It's not as simple as opening the file and stripping out anything that starts with <script>. Code can be fired on almost any user event and it can be attached to almost any high-level object. It's not impossible to create a scrubber but it's a lot more complicated than you might think.

I spent the better part of a week attempting to create a PDF scrubber at my office for this same reason. We had become victim to highly targeted attacks from PDF sources. I wrote a scrubber in PHP using an open-source PDF parser [setasign.de] and a series of regular expressions to strip out any javascript. At the end of the day, I came very close to a working solution but I ran into issues with encrypted PDF's.

The project was shelved in favor of making users open all external PDF's on a virtual server that was hardened and re-imaged every evening to prevent any malicious code from running rampant. That's the simplest solution.

Re:Print to PDF (0)

Anonymous Coward | about a year ago | (#44314511)

Agreed, and for this reason I'd definitely not use Adobe products. At the simplest level, using something like pdftops to write to Postscript file. You could then extract the image objects, re-render them, and replace. I helped write some of the code (long obsoleted) for some early rasterizers and the Javascript doesn't survive :).

Re:Print to PDF (3, Interesting)

fuzzyfuzzyfungus (1223518) | about a year ago | (#44314571)

Out of curiosity, were you dealing with enough fancy-forms-and-interactive-nonsense type PDFs that the 'just brutally rasterize it and let them eat .jpeg!' option wasn't an option, or were the attackers good enough that you didn't have a PDF renderer you could trust for the rasterizing duties?

Re:Print to PDF (-1)

Anonymous Coward | about a year ago | (#44314977)

I wrote a scrubber in PHP

Well, maybe if you learned how to use a real programming language you'd have had better luck. I wouldn't try writing this kind of thing in Perl or Bourne Shell either.

Re:Print to PDF (0)

Anonymous Coward | about a year ago | (#44314707)

Maybe dumb question, not an expert - if I were to print to pdf (OS X), would the file thus created be stripped of embedded Javascript? Tnx.

Re:Print to PDF (1)

Anonymous Coward | about a year ago | (#44314901)

Somewhat good solution.
Problem: text fields are no longer editable. So all PDF files have to be signed/fileld manually.

Be careful modifying documents (5, Informative)

Anonymous Coward | about a year ago | (#44314191)

You can change the legality of a document for example by modifying it.

A solution that modifies the PDF viewer is much better than one that alters the document. That means not using Adobe. Pity the company refuses to build a version that doesn't do Javascript in the first place.

Re:Be careful modifying documents (4, Informative)

macbeth66 (204889) | about a year ago | (#44314669)

I believe that for a PDF document to be a legal document, it needs to be in PDF/A format. This format prohibits the use executable code, such as Javascript.

Re:Be careful modifying documents (4, Insightful)

godrik (1287354) | about a year ago | (#44314809)

Where does this belief comes from? Why would there be any format requirement on these things? The requirement would need to be in the law or in a court judgment. Is the law going to be that precise over electronic communications? (Not trying to bitch, just really wondering)

Sumatra PDF (0)

Anonymous Coward | about a year ago | (#44314197)

Sumatra PDF:
http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html

It doesn't get nailed by viruses and security breaches like Adobe's PDF reader. And, it doesn't have adware in the installer like FoxIt. And, he releases updates regularly.

I used to use FoxIt a long time ago, but have since switched to Sumatra. Never looked back, it does the job.

Re:Sumatra PDF (2)

X-Dopple (213116) | about a year ago | (#44314255)

A big limitation of Sumatra is that it doesn't support filling out interactive forms, which makes it a no-go in my organization

Re:Sumatra PDF (1)

Em Adespoton (792954) | about a year ago | (#44314335)

A big limitation of Sumatra is that it doesn't support filling out interactive forms, which makes it a no-go in my organization

If it fills in forms, it's a security risk. I seem to recall that there are a few that ignore forms and let you create companion files that do overprint forms on form-like fields though. Can't remember the names offhand.

Re:Sumatra PDF (0)

Anonymous Coward | about a year ago | (#44314597)

I used to use FoxIt a long time ago, but have since switched to Sumatra. Never looked back, it does the job.

You did look back — how else would you have remembered that you used to use Foxit?

Sumatra PDF (5, Insightful)

shellster_dude (1261444) | about a year ago | (#44314201)

Check out Sumatrapdf http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html [kowalczyk.info] . It's super fast and does not support javascript or actionscript in PDF's. I use it exclusively now.

Re:Sumatra PDF (2)

Em Adespoton (792954) | about a year ago | (#44314347)

Check out Sumatrapdf http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html [kowalczyk.info] . It's super fast and does not support javascript or actionscript in PDF's. I use it exclusively now.

Is it vulnerable to font description overloading and the other PDF exploits out there? A large portion of the malicious PDFs I've seen lately didn't use forms or javascript containers as the main attack vector (usually shellcode via some markup bug).

Re:Sumatra PDF (1)

Anonymous Coward | about a year ago | (#44314411)

They address what few security vulnerabilites exist in the software immediately, it's based on MuPDF library.

Easy (1)

Sparticus789 (2625955) | about a year ago | (#44314207)

The best way to protect your computer from malicious Javascript embedded within a PDF is to not install Adobe Reader. If you cannot open the file, your computer cannot be infected.

Re:Easy (1)

plover (150551) | about a year ago | (#44314421)

That's almost 100% correct. The problems could potentially be infecting a document previewed or even the search indexer, though. There have been successful attacks on Windows taking advantage of the JPEG previewer as well as WMF, TTF, and others.

I don't know of any such successful attacks on Windpws 7 or higher. Doesn't prove they're impossible, just that they haven't been encountered yet.

Re:Easy (1)

sjwt (161428) | about a year ago | (#44314439)

Nuke them from orbit--it’s the only way to be sure.

javascript? (4, Insightful)

sjames (1099) | about a year ago | (#44314209)

Why in the world is javascript included in PDF documents? PDF is already a Forth like programming language and environment.

Re:javascript? (2)

jbolden (176878) | about a year ago | (#44314297)

I think you are thinking PostScript. PDF requires that all computations resolve to a well defined value based on information contained within the document (i.e. not turning complete). So then of course Adobe had to add a turing complete language back in.

Re:javascript? (1)

sjames (1099) | about a year ago | (#44314531)

I am more familiar with PostScript (by way of Forth (Warnock can claim they're unrelated all he wants). Looking further, I see that PDF strips out flow control. Perhaps they should just put it back?

Re:javascript? (3, Interesting)

fuzzyfuzzyfungus (1223518) | about a year ago | (#44314677)

I think you are thinking PostScript. PDF requires that all computations resolve to a well defined value based on information contained within the document (i.e. not turning complete). So then of course Adobe had to add a turing complete language back in.

I don't know if any implementations are stupid enough to implement this(at least without some very careful sanitizing); but(in addition to ramming in javascript and the ability to embed basically anything at all, thanks for nothing 'rich media annotations'), they even added: Launch Actions!

"12.6.4.5 Launch Actions
A launch action launches an application or opens or prints a document. Table 203 shows the action dictionary
entries specific to this type of action.
The optional Win, Mac, and Unix entries allow the action dictionary to include platform-specific parameters for
launching the designated application. If no such entry is present for the given platform, the F entry shall be
used instead. Table 203 shows the platform-specific launch parameters for the Windows platform. Parameters
for the Mac OS and UNIX platforms are not yet defined at the time of publication."

Your Standards Compliant Solution for executing arbitrary binaries with arbitrary parameters. No need for messy, version-sensitive, exploit code! Combine with javacript and web-interaction support to build documents that search the target's hard drive for interesting things upon being opened... Or(miracle of miracles!) build a PDF that runs the adobe update utility when you open it, you're sure to find something new every time!

Re:javascript? (1)

mysidia (191772) | about a year ago | (#44314865)

Will the next version of reader come complete with a PWN ME sign hung automatically around the back of your computer, and included in the Acrobat plugin version string announced by the web browser in the User Agent headers towards every site you visit?

Re:javascript? (0)

gweihir (88907) | about a year ago | (#44314333)

I suspect most people (and malware programmers ;-) are not capable of writing PostScript, regardless of it being a full-featured programming language. Hence JavaScript, the bastard-cretin of the programming language world, got included. Personally, i find the only thing difficult in PostScript is handling fonts. But that may also be because what I wanted to do, I could well do without fonts.

Re:javascript? (2)

Gothmolly (148874) | about a year ago | (#44314473)

Because in the post-Microsoft world, there is no separation between code and data. Where have you been since 1991?

Why sanitize the pdf file? (2)

140Mandak262Jamuna (970587) | about a year ago | (#44314249)

Why don't you sanitize the reader? Use a reader with javascript ignored. Or build one from whatever open source pdf reader you can find, if there isn't one already. Or run the pdf reader inside a sandbox without internet access or permanent disk write. If that breaks the portability and the documents don't render correctly when javascript is diabled, tell the sender and blacklist the sender too for good measure. If enough companies lock javascript out of pdf documents eventually the authoring tools will stop using it.

This entire approach is wrong (1)

93 Escort Wagon (326346) | about a year ago | (#44315091)

The submitter is looking for a code-based solution to a sociological/psychological problem, and it's just not going to be effective.

The real solution is to educate and train your users so they don't fall prey to these sorts of attacks. I know a lot of IT people aren't comfortable dealing with people, and I know it takes quite a bit of time and doesn't look as snazzy on your résumé - but, really, it's the best long-term approach.

Just block PDFs with javascript (2)

Kardos (1348077) | about a year ago | (#44314261)

You don't need a solution that rewrites the PDF. At best it will work correctly "most of the time", and break PDFs the rest of the time. For example, pdf->ps->pdf, or the "print to pdf" solution mentioned earlier in the comments may work fine for scanned PDFs, but if there are annotations/comments then they'll get stripped. This will lead to massive user frustration ("but the comments are there, I sent it in the last email") and people having to find ways to work around your filter. Modifying people's attachments is a bad move. A more reasonable solution is to detect if the PDF contains any javascript code, and if it does, block the PDF entirely.

Re:Just block PDFs with javascript (3, Funny)

Kardos (1348077) | about a year ago | (#44314295)

Looks like these guys made a tool to do the JS detection: http://www-rsec.cs.uni-tuebingen.de/laskov/papers/acsac2011.pdf [uni-tuebingen.de]

Re: Just block PDFs with javascript (5, Funny)

Anonymous Coward | about a year ago | (#44314507)

That link is to a PDF! How do I know it's not a trap? Oh, the dichotomy :-(

Re:Just block PDFs with javascript (-1)

Anonymous Coward | about a year ago | (#44314885)

This. It's a better solution than blocking pdf entirely, though adobe deserve it for doing something as boneheaded as adding javascript and "interactivity" back in to pdf. It means overloading of the format and makes for trouble exactly like this. The only real reason we use it is because all the alternatives are either worse (".doc") or not spiffy enough (plain text, though it should be used far more often than it is now).

Most importantly, rejecting the mail entirely puts the problem right back where it belongs ("don't send this crap, eh") and doesn't beget quite as much user frustration --and support calls-- as automatically butchered attachments would. Still, be sure to communicate very clearly within the organisation that you're blocking certain kinds of attachments and so if something doesn't get through it'll be because of that.

RE:Ask Slashdot: How Do You Automatically Sanitize (1)

MobSwatter (2884921) | about a year ago | (#44314285)

"Your document has been completed Sent on behalf of *. All parties have completed the envelope 'Please DocuSign this document: To All Employees 2013.pdf'. To view or print the document download the attachment . (self-extracting archive, Adobe PDF) This document contains information confidential and proprietary to * LEARN MORE: New Features | Tips & Tricks | Video Tutorials DocuSign. The fastest way to get a signature. If you have questions regarding this notification or any enclosed documents requiring your signature, please contact the sender directly. For technical assistance with the signing process, you can email support. This message was sent to you by * who is using the DocuSign Electronic Signature Service. If you would rather not receive email from this sender you may contact the sender with your request." They are zero day exploits... The funny thing is, the more I try to piss off elite corps and gov't, the more of these I get. No law against testing the "system".

Rasterize and reencapsulate (1)

gweihir (88907) | about a year ago | (#44314293)

The problem is that PDF and the PostScript used in it is an executable language. This falls under "executable code in non-executable containers". If you need to be sure, convert the PDF to a series of JPG or GIF pictures and recreate a PDF from them. With any less harsh approach, you may retain malicious PostScript (and other) code.

And, yes, what you are trying to do is non-trivial. Expect anything "simple" will be insecure.

Re:Rasterize and reencapsulate (3, Informative)

Kardos (1348077) | about a year ago | (#44314355)

If you rasterize and re-encapsulate your user's PDF attachments, your users will hate you, and work around your "stupid filter that breaks pdf attachments". You are better off blocking all PDF attachments by email. It'll save yourself a ton of work, and your users can skip the frustration of mangled attachments and go directly to working around your filter.

Re:Rasterize and reencapsulate (2)

gweihir (88907) | about a year ago | (#44314417)

Your problem only applies if the PDFs have to be editable or if you rasterize with too low or too high resolution. You can also run the images through OCR to get back come level of editability.

Otherwise you have work with possibly infected PDF. There are a few settings where that is not acceptable and users will not work around it (e.g. "you infect this system and then it turns out you where not following procedure, you go to prison for a few years"-environments.)

While I agree that security should not hinder users from doing their job exactly because they will otherwise start to work around it, that was not the question of the OP.

Re:Rasterize and reencapsulate (1)

Kardos (1348077) | about a year ago | (#44314469)

If users will be fired/jailed for working around a PDF mangling filter, the solution is to ban all PDFs, not mangle them and expect the users to keep doing their jobs. Permit raster image attachments, not PDFs.

Re:Rasterize and reencapsulate (1)

gweihir (88907) | about a year ago | (#44315087)

And what if these users have to work with things sent in from the outside world? Fail!

Re:Rasterize and reencapsulate (1)

Anonymous Coward | about a year ago | (#44314425)

If you rasterize and re-encapsulate your user's PDF attachments, your users will hate you, and work around your "stupid filter that breaks pdf attachments". You are better off blocking all PDF attachments by email. It'll save yourself a ton of work, and your users can skip the frustration of mangled attachments and go directly to working around your filter.

I saw a large contract walk out the door as a result of a mangled attachment. After several rounds of sending and re-sending, the two managers ended up arguing about who was fucking up the file, and eventually the other guys just figured we were idiots and walked away.

Re:Rasterize and reencapsulate (0)

Anonymous Coward | about a year ago | (#44314575)

If you rasterize and re-encapsulate your user's PDF attachments, your users will hate you, and work around your "stupid filter that breaks pdf attachments". You are better off blocking all PDF attachments by email. It'll save yourself a ton of work, and your users can skip the frustration of mangled attachments and go directly to working around your filter.

I saw a large contract walk out the door as a result of a mangled attachment. After several rounds of sending and re-sending, the two managers ended up arguing about who was fucking up the file, and eventually the other guys just figured we were idiots and walked away.

Clearly there was more than one fucking idiot who couldn't come up with another way to transmit a file from one location to another. These old fashioned things called fax machines and even snail mail still do work. And damn near every single time I hear. Obviously the contract wasn't worth the 2 minutes of common sense effort.

Aren't assumptions a bitch...

Re:Rasterize and reencapsulate (0)

Anonymous Coward | about a year ago | (#44314857)

I've seen customers leave because they couldn't figure out how to open the zip file containing the product. Instead they thought we were jiving them and sending garbage. Turns out he was renaming the file extension to what he thought was proper and loading it in autocad.

Re:Rasterize and reencapsulate (1)

toejam13 (958243) | about a year ago | (#44315099)

My wife's old scanner software used to scan documents into multi-page TIFF files. She had one client whose image viewing/printing software would only recognize the first page embedded in the file. After a couple of rescans/resends, the client was ready to walk. I had to download a PDF conversion program for her so that her client could view the other pages.

Some people have very little patience and will quickly walk if any issues with communication arise. That's life.

You don't (5, Interesting)

PNutts (199112) | about a year ago | (#44314319)

At some point you trust technology and also reinforce proper user behavior. I hate catch-phrases but your e-mail hygiene should have layers of protection (defense in depth). Assuming that the message got through IP reputation filters, SPAM analysis, malware scans, and was delivered to your user, you rely on desktop protection and cross your fingers that nobody opens it.

We have SMTP appliances from Axway and we used to stop all executable attachments and deliver a notification to the user to call the help desk and request a release. Times changed and we don't do that any more. However, you could annotate the message to remind the user that if they don't know who it's from or what it is or if they weren't expecting it to not open it. And some will anyway. We also used to hold certain attachments for four hours until the virus definitions (and the other defenses) received a couple of updates and then reprocess the message.

If you do try to roll your own, be aware that everyone and their dog creates PDF files with varying degrees of success and we had certain PDF files that caused services to fail on our gateway while they tried to scan and process them. You didn't mention the volume but make sure your solution scales well.

Re:You don't (0)

Anonymous Coward | about a year ago | (#44314437)

and we had certain PDF files that caused services to fail on our gateway while they tried to scan and process them

Ya, you can target the sanitizers with all kinds of fun stuff. They usually just end up becoming a new point of failure.

Re:You don't (1)

King_TJ (85913) | about a year ago | (#44314445)

I'm thinking along the same lines here.... I can't say that I've really seen Javascript embedded PDFs as much of an attack vector where I work. By and large, your Mac OS X users wouldn't encounter this anyway, since they generally use the "Preview" app that's part of the OS to view and print PDFs. Adobe Reader is usually rather pointless to install in OS X, since Preview renders pages far faster anyway AND gives the ability to do things like add signatures to a document, re-order the pages and annotate, without paying for the abilities.

I'm sure this could eventually be an issue for some of our users, but you'd hope the desktop anti-virus software might stop it from doing damage too, depending on what it was attempting. But even if not? You can't protect against everything, and you reach a point where the solutions are as bad as the problems since they start impacting productivity and slowing down EVERYONE, all the time, just to try to block the one hypothetical attack.

At least in Windows, I wish sometimes the OS had the capability of opening all attached executable type files from email in sort of a "sandbox". Only after a file was determined to be something the user actually wanted to use/print/keep would they get the option to transfer it over to the regular file system. (When you think about it, almost all the malware that gets in by tricking a user into opening the attachment would at least get caught at THIS level. They almost always realize after running the file that, "Hey, that didn't seem to do anything!" or "That did something weird to my system... Oh no!", or even "That's not the document the email said it was going to be!") It's that curiosity or initial confusion that makes them open the bad stuff in the first place -- and a sandboxed "safe zone" to do that in would let them do it while mitigating the risk.
 

evince (1)

davydagger (2566757) | about a year ago | (#44314331)

Evince is the PDF/Documents viewer for gnome, It also gets compiled for windows.

In the linux world, its a heavy weight gnome app.(compared to e/x pdf), but its far far far lighter than Adobe Acrobate Reader, and it doesn't do javascript at all. I've yet to come accross issues with PDFs not working, as most legimiate PDFs don't use javascript.

It also comes from a long standing respected open source project, GNOME,(read comparable quality as commericial software,), not a drive by night freeware operation of dubious origins.

https://wiki.gnome.org/Evince/Downloads

Use sandboxie (3, Informative)

zenlessyank (748553) | about a year ago | (#44314349)

Great little app for just such issues.

Re:Use sandboxie (1)

Anonymous Coward | about a year ago | (#44314565)

Any root exploit is also a break-out-of-sandboxie exploit, if the exploit creator decides to include that.

cum (-1)

Anonymous Coward | about a year ago | (#44314393)

problem stems and has instead Than a fraction of OpenBSD. How many users of BSD sadness And it was all along. *BSD BSD machines, Guests. Some people If I remain comprehensive work that you Suffering *BSD officers. Others to download the won't vote in series of 3xploding this is consistent the project is in Nearly two years This post brought like they are Come Are you GAY May disturb other

Change configuration (0)

Anonymous Coward | about a year ago | (#44314397)

Adobe Reader (XI, other releases?) can be used in Protected Mode.

Edit>Preferences>Security(Enhanced), check Enable Protected Mode at Startup, All files and check Enable Enhanced Security. And disable Javascript.

I wouldn't say it's possible to definitely sanitize a malicious document, but enabling some of the security features is going to make exploitation more challenging.

Re:Change configuration (3, Insightful)

fuzzyfuzzyfungus (1223518) | about a year ago | (#44314691)

And be sure to double-check that the next update doesn't revert those settings on you...

Whatever you do, do it in a sandbox (0)

Anonymous Coward | about a year ago | (#44314405)

You're going to be automatically opening PDF from the internet, so whatever you do, do it in a sandbox.

Why are you doing this? (0)

tftp (111690) | about a year ago | (#44314449)

Before you jump in and start messing with corporate documents, make sure you understand very well why you are doing it in the first place. Is it what you are specifically hired to do? Some PDFs are cryptographically signed, and there is nothing that you can do to alter them that won't invalidate the signature. Other PDFs are password-protected from copying. You cannot legally extract their content (even if technically there are ways.) Malicious content inside a PDF is, therefore, not blockable unless you block all PDFs - and then you will cause more harm to the business than all the PDF viruses taken together. The best solution is to enforce a safe reader.

Re:Why are you doing this? (1)

king neckbeard (1801738) | about a year ago | (#44314459)

Aren't the signed PDFs usually just signed in Adobe, but read just fine in lmost any other reader?

Re:Why are you doing this? (4, Informative)

tftp (111690) | about a year ago | (#44314501)

Signed PDFs can be read in any reader, but the signature will be still validated (if the reader is not defective.) Encrypted PDFs will not be even readable if they are not encrypted to you. Password-protected PDFs may require the password to be readable, let alone printable or changeable.

In other words, PDFs are not designed for wanton modification. Some of them can be modified, but others cannot. This means that you cannot build a reliable method for converting suspect PDFs into safe PDFs.

Re:Why are you doing this? (1)

king neckbeard (1801738) | about a year ago | (#44314609)

I seem to recall a lot of the security mechanisms assuming you are using Adobe. I want to say that passworded files will often just ignore the password prompt and display normally, and if a PDF can be read, it can be printed.

Re:Why are you doing this? (1)

tftp (111690) | about a year ago | (#44314653)

I want to say that passworded files will often just ignore the password prompt and display normally, and if a PDF can be read, it can be printed.

It's because there are two passwords; one to open for reading, and another for other purposes. Let me open Acrobat and tell exactly...

  • Four security methods: None, Password, Certificate, Adobe LiveCycle DRM
  • Password uses AES256; encrypts all, all ~metadata, only attachments
    • Require password to open: Y/N
    • Require password to print: Y/N (if Y then select output resolution)
    • Require password to edit: Y/N (many options)
    • Enable copying of text, images, etc.
    • Enable screen readers

The certificate security seems to support that too. It's a complicated cardhouse, and I wouldn't want to become responsible for hacking it. Not as a volunteer, at least (no "thank you" if it stops a virus, but all the blame if it breaks someone's workflow.) Generally, if a PDF is signed or certified or encrypted, it's off limits. I do sign PDFs now and then, and I have seen workflows where *every* PDF is signed (the government does that.) Those are not something you dare to hack - those are often multimillion contracts awarded to your company.

Re:Why are you doing this? (1)

Z00L00K (682162) | about a year ago | (#44314839)

And there are software out there that removes all limitations on a PDF too.

Of course - mostly useful when you want to be able to enable the ability to copy text from a PDF or remove watermarks and similar stuff.

Re:Why are you doing this? (1)

tftp (111690) | about a year ago | (#44314897)

That software cracks the password(s) by brute force. As I understand, there are not too many better attacks against AES. This means that a password like 9~}~w\1[X\3{F968|05|\St3\Ya7Lh~~ is not going to be cracked in this millennium. Besides, it would be entirely illegal to use such software in a business. Cracking of a password may take a second, or it may take a year. How would you integrate that into your mail processing chain?

PDF can be also encrypted with PKI, and with Adobe's own DRM. Those cannot be cracked, as far as I know. You either attack the symmetric cipher, which is usually AES256, or you find a new attack against RSA. If you can do either of those in reasonable time, you have better things to do - like becoming filthy rich and famous. (Or dead.)

Re:Why are you doing this? (1)

Bert64 (520050) | about a year ago | (#44315107)

Cracking the password is entirely different from removing the "limitations"...
If you can open the file and read it, then you can always modify, print, copy etc the file too. If you can read the file then you have already got past the encryption because either there is no encryption or you have the key.

Re:Why are you doing this? (1)

Bert64 (520050) | about a year ago | (#44315103)

The only option remotely useful, is the one to encrypt the file with a password for opening. The other "features" are just stupid client side security, and only appear to work if the client respects the options. All the user has to do, is open the file with a different pdf reader that ignores the options. Options like this are actually worse than having no options at all, because they create a false sense of security and encourage users to use them.

If you can read the file, you can always copy data out of it, print it, edit it etc.

Solution is here .. (0, Flamebait)

dgharmon (2564621) | about a year ago | (#44314457)

Download and install Ubuntu [ubuntu.com] or one of these distros [distrowatch.com] ..

Anything but Adobe (2)

king neckbeard (1801738) | about a year ago | (#44314497)

If you use anything but Adobe, it probably won't support javascript because it's fucking stupid to have javascript in a PDF. Just avoid Adobe, because they are allergic to security.

Test the Attachments (3, Interesting)

Flere Imsaho (786612) | about a year ago | (#44314567)

There's a couple of vendors (and many more playing catch-up) selling appliances that detonate attachments on sandboxed VMs running in fast virtual memory.
They executed/open attachments and watch to see what happens - registry changes, file drops, network activity, attempts to contact known C&C servers, etc.
Anything that exhibits non-legit behavior get quarantined. FireEye have a box that does this and also crawls network shares, testing files.

Aside from whitelisting, I think it's the best defense against zero day malware. It's a little too pricy for the company I work at right now, but as more vendors add this functionality, the price will come down.

Re:Test the Attachments (2)

Kardos (1348077) | about a year ago | (#44314613)

Until you get malware that is smart enough to detect if it's in a VM, only activating when it's not in a VM...

Re:Test the Attachments (0)

Anonymous Coward | about a year ago | (#44314759)

Then you just have all of your clients run hypervisors and do everything in VM. Problem solved.

(Kidding, but that might not actually be a horrible idea.)

Re:Test the Attachments (3, Funny)

ZzzzSleep (606571) | about a year ago | (#44314779)

Then just do all your work in a VM, and you'll be safe from malware!

Okular? (0)

Anonymous Coward | about a year ago | (#44314637)

I was surprised that nobody mentioned it so far. Is it the case that nobody uses KDE these days? (KDE SC can be installed and run on a windows box as well)

And I believe there are programs that convert PDF's to ps's so none of the executable stuff are kept. Whether those will survive legal challenges when some comes up, well, that's for another discussion.

and if you are more cautious than that, set up vm's for these and you have snapshots when things go wrong.

You Don't (5, Interesting)

SuperCharlie (1068072) | about a year ago | (#44314665)

For a long time, I thought like you, that it was my duty to ward off and protect the "children". After a while, you realize 2 things.

First, it is most likely your duty to inform and educate. Do that. Do it well, do it loud, and do it as often as you can. When someone eventually opens up one of those attachments, it will get around, and peer pressure will make everyone else gun-shy. After a user or two of mine got bit by an attachment, and I had repeatedly warned my users about these things.. I ended up with people at my desk occasionally asking..can you come look at this.. it just looks funny.. it was all about the peer pressure and not wanting to be That Guy who clicked the stupid link.

Second, and I hate to say it, this is what we do, and this is job security. You can't save em all Hasselhoff, if ya did, there would be nothing left to do..

Take A Step Back (0)

PairOfBlanks (2952901) | about a year ago | (#44314667)

Re-evaluate the use-case for the whole PDF attachment. I can't think of a single _good_ reason to use it, ever. If somebody tries to give a false reason why it's a necessary format, just explain to them in technical detail why it's bad. I'm hoping that somebody can reply to this with a _genuine_ reason why sending a PDF (Pretty Damn F'ked) attachment to an e-mail is either necessary or optimal. 'It's good looking' sounds like a weak reason.

Re:Take A Step Back (3, Insightful)

tftp (111690) | about a year ago | (#44314735)

I'm hoping that somebody can reply to this with a _genuine_ reason why sending a PDF (Pretty Damn F'ked) attachment to an e-mail is either necessary or optimal

What else would you use to send an invoice, or a contract, or a drawing, or a user's manual, or anything else that requires pixel-accurate placement of all elements as designed ? It has to support digital signatures as a minimum, and preferrably a complete public key encryption. PDF does that.

'It's good looking' sounds like a weak reason.

The 'good looking' is a weak reason. "Correct" is a far better reason. Once you print into a PDF, it captures your document exactly as it is. You want your documents to represent what you put into them - neither more nor less. Perhaps there are better formats, but I'm not aware of any.

Re:Take A Step Back (1)

PairOfBlanks (2952901) | about a year ago | (#44314773)

Good thoughts. I was thinking (not written well) about what PDF does better than other pixel-accurate formats (such as postscript). In other words, I was looking for something above-and-beyond the competition effectively justifying the sanitization effort that the OP will have to put forth (as many unfortunately don't).

confining javascript (2)

Skapare (16644) | about a year ago | (#44314719)

Javascript should not be given the capability of doing damaging things, It should be confined to a narrow execution context that is limited to being able to do only the things that enhance the experience of that ONE information resource. Dynamic layout is certainly a useful thing. Dynamically changing your system is not. It should not have access. I blame the developers. It doesn't matter if it is mail or web. It might do cute things inside a PDF like give you a calculator for a certain algorithm the PDF is written about. But it should not be able to access even /etc/hosts on your computer.

Re:confining javascript (1)

phantomfive (622387) | about a year ago | (#44314853)

You are not the only one who thinks this, the problem is things designed this way are rarely as secure as the designer wishes. See for example, Java Applet exploits.

Other options not always an option (4, Insightful)

fermat1313 (927331) | about a year ago | (#44314817)

Lots of people here saying "Don't use Adobe" and suggesting alternatives. Reality is, for many of us, we deal with complex PDF forms and applications that integrate directly with Adobe Acrobat. In my business (CPA firm) we use lots of applications, and most of them are highly vertical with often just one realistic competitor that can function adequately for a firm our size. Many of our apps integrate directly with Acrobat (and Office) so not using Acrobat simply isn't a choice we can make.

So how do we deal with Adobe Acrobat? As some pointed out earlier, defense in depth. Spam filters, multiple virus scans, and our two most important measures: End users don't have admin on their computers and Adobe is one of our "High Priority" upgrade applications. Updates must be pushed out within one day of being released.

BTW, the other other High priority apps are Java and Flash, again, both required by our software. With Acrobat, they make up my "Axis of Evil" of insecure software.

xpdf doesn't support javascript (1)

Narcocide (102829) | about a year ago | (#44314923)

just sayin... you could simply use a more secure pdf reader.

So the real question is... (0)

Blugenes (2987347) | about a year ago | (#44314943)

...are you saying Earth was the victim of a planetary-scale golden shower at some point?

Re:So the real question is... (2)

Blugenes (2987347) | about a year ago | (#44314957)

Ignore and erase if possible, posted in wrong thread by accident

simple (1)

Kishin (2859885) | about a year ago | (#44314959)

Use Foxit and keep javascript off by default. (Or don't even install the JavaScript plugin.) It's lightweight, fast and has fewer quality issues than adobe. Additionally, considering PDF is inherently an unsafe format, I'd say adding a sandbox like Sandboxie can help you. More technical people here might try porting a good PDF reader's key parsing and JS functionality to NaCl sandboxing system. Put each component in separate partitions with inner sandbox protection at a minimum. That lets us use the fast and legacy native code, but have plenty isolation almost for free. Nick P Security Engineer usually on schneier.com

SumatraPDF (1)

thelukester (2722207) | about a year ago | (#44314999)

Simple. In our organization, Sumatrapdf is the only allowed PDF reader. Users could request nitro or foxit but a sysadmin would disable JavaScript on install. Never once had a malicious PDF infect our organization. Little more work to not give users admin rights to their machines. But time and time again, users prove they are too incompent to safely manage their own machines.

PDF2PS (0)

Anonymous Coward | about a year ago | (#44315007)

And moron who allows attachments should be fired.

We allow authorized persons to upload files. 100% of attachments are trashed. Emails with pictures or questionable html, attachments or other tripe are stripped to raw text. There is a zero tolerance policy on personal devices connecting to the internal net and this includes USB or other devices. If you find you can't do your job with all the twiddly blather there's a line at the door.

Wrong Place to Address the Issue (0)

Anonymous Coward | about a year ago | (#44315047)

Scrubbing JS from all PDF files is only one step below blocking PDF outright. Sysadmins have to understand that you can't combat ignorance and stupidity with technology. It's never going to work. We've spent the last two decades trying to block this exploit and that, but has it made us safer? No, it hasn't. You know why? Because people are gullible, that's why. You can't fix that. Just design your systems so that critical infrastructure isn't damaged or disrupted by stupid users.

Ditch acrobat (1)

Bert64 (520050) | about a year ago | (#44315057)

Seriously, why do people still run acrobat? PDF is a standard format, there are countless programs which support it and the only reason such files are a target is because adobe reader is basically a monoculture and represents a very large and attractive target. We need diversity among PDF readers, just like diversity among web browsers. It was diversity among web browsers more than anything else that reduced browser attacks and caused hackers to concentrate on proprietary monoculture plugins instead.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

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>