Ask Slashdot: How Do You Automatically Sanitize PDF Email Attachments? 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."
Foxit Reader? (Score:5, Informative)
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? (Score:4, Informative)
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? (Score:5, Insightful)
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: (Score:3)
Re: (Score:2)
Corporate policy could enforce an alternative PDF reader. And everyone would be happy as PDF viewing would be a much nicer, faster, experience.
Re: (Score:2)
Yeah, but if your sanitizing is defective in some way and you load into Adobe Reader, the remaining JS will still execute. With a reader that is incapable of running javascript, it doesn't matter.
On the flip side, if you don't sanitize the JS and pass the file along to an unsuspecting 3rd party, they may get infected. So the best option seems to be to do both: try to strip JS from the files and use a reader that doesn't parse JS.
Re:Foxit Reader? (Score:5, Informative)
I run a ghostscript shell script to print a PDF as a new PDF:
gs -dNOPAUSE -sDEVICE=pdfwrite -sOUTPUTFILE=NEW_FILE.pdf -dBATCH OLD_FILE_1.pdf OLD_FILE_2.pdf
In this case OLD_FILE_1.pdf and OLD_FILE_2.pdf will be combined into NEW_FILE.pdf. AFAIK this strips javascript.
Re: (Score:2)
Because, ironically enough, the newer versions run embedded Adobe Flash for visual weather maps.
Re: (Score:2)
Re: (Score:2)
I think GP was mixing privacy and security...
Re: (Score:2)
If you want it gone, spray it with FOOF [corante.com]
Re: (Score:2)
Nitro and foxit now display JavaScript. You can disable it in options. Unless you want to use old versions, your best bet is sumantraPDF.
Re: (Score:3)
As far as I know, Foxit Reader strips out any JavaScript. The PDF readers in Chrome and Firefox also should do the same.
That ony prevents it running on the machine used to view it - it's still in the PDF. The best way is to either insist on PDF/X or convert to it. PDF/X does not allow active content such as scripting, etc.
Print to PDF (Score:5, Informative)
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 (Score:5, Informative)
Like
lpr -P Cups-PDF file.pdf
Re:Print to PDF (Score:5, Interesting)
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 (Score:4, Interesting)
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 (Score:5, Funny)
Re: (Score:3)
Actually, you may have hit upon a pretty good idea there.
Use ImageMagick to convert the PDF to PNG or TIFF then convert it straight back again.
Potential drawbacks:
- Would your mailserver now become the target for those attacks?
Re:Print to PDF (Score:4, Informative)
Re: (Score:3)
Man, don't bash bash! It's awesome and most tools that do real work are written in C anyway. It is just the glue between small tools.
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Be careful modifying documents (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:5, Insightful)
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)
Re:Be careful modifying documents (Score:5, Informative)
I believe that for a PDF document to be a legal document, it needs to be in PDF/A format.
Where does this belief comes from?
Many states have legislation regarding the font, margins and paper sizes used for some legal documents.
US courts, archivists and many case management / COPS systems only accept documents in PDF/A.
Sumatra PDF (Score:5, Insightful)
Re: (Score:2)
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: (Score:2)
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.
Sumatra PDF used to be light, a mere 800 KB, I just installed the latest version, a whopping 3.6 MB. It's suffering the same form of featuritis as the other PDF readers I dumped because they became slow and unwieldy (Adobe and Foxit).
Easy (Score:2)
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: (Score:2)
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: (Score:2)
Nuke them from orbit--it’s the only way to be sure.
Re: (Score:2)
http://starcraft.wikia.com/wiki/Purification [wikia.com]
javascript? (Score:5, Insightful)
Why in the world is javascript included in PDF documents? PDF is already a Forth like programming language and environment.
Re: (Score:3)
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: (Score:2)
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: (Score:2)
Well the idea of PDF was to avoid indefinite resolution, inconsistent RIP times.... I think it makes more sense to keep it out but I'd say really the question is, "why not bring back Postscript for more complex documents"?
Re: (Score:3)
So we agree. As an aside, I don't think inconsistent RIP times mean as much for print as they did. You'd be hard pressed to find an engine 2.5x faster than the one you would get in a good quality commercial printer of the same form factor in the mid 1990s. At the same time you would be hard pressed to find a RIP that wasn't at least 25x as fast as one from the mid 1990s. RIPing is so fast relative to other parts of the engine that there aren't dedicated hardware RIPs at all, it is just a process you thro
Re:javascript? (Score:4, Interesting)
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: (Score:2)
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: (Score:2)
Wow! .pdfs become binaries. Talk about a glaring security hole.
Re: (Score:3)
Because in the post-Microsoft world, there is no separation between code and data. Where have you been since 1991?
Re: (Score:2)
Because Adobe PDF Reader is not - and hasn't been for some years, if ever - a plain PDF viewer. It's not meant to be.
It's a fat-client application for a whole lot of other products that need to produce interactive forms that require both the presentation to the user and the end result to look predictable.
99 times out of 100, nobody needs this functionality. But for that 1 time out of 100 where it is needed, Adobe's salesmen have a nice easy job: "No obscure third-party software required by your clients in o
Why sanitize the pdf file? (Score:3)
This entire approach is wrong (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
I am intreagued by your solution, and would like to subscribe to your magazine.
Just block PDFs with javascript (Score:3)
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 (Score:4, Funny)
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 (Score:5, Funny)
That link is to a PDF! How do I know it's not a trap? Oh, the dichotomy :-(
Re: (Score:3)
bonus points awarded for linking to a pdf.
Re: (Score:2)
It is like the executable files restriction. It does not really hinder you, since you can always encrypt zip the files you want to send. It is an almost win-win situation, in that all bad attachments are rejected and the few users that do need the feature, it takes them only 10s more effort. Huge security gain, little effort on the users.
But I would not drop or reject the email, I would remove the attachment and attach an atachment-deleted.txt. This allows the user to react to the communication, even though
Rasterize and reencapsulate (Score:2)
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 (Score:4, Informative)
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: (Score:3)
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 hinde
Re: (Score:2)
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: (Score:2)
And what if these users have to work with things sent in from the outside world? Fail!
Re: (Score:2)
You don't (Score:5, Interesting)
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: (Score:2)
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,
Re: (Score:2)
evince (Score:2)
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 d
Anything but Adobe (Score:3)
Test the Attachments (Score:4, Interesting)
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: (Score:3)
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 (Score:4, Funny)
You Don't (Score:5, Interesting)
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..
How hard could it be? (Score:2)
Learn the file format and write a program to strip out any executable script elements.
http://www.adobe.com/devnet/pdf/pdf_reference.html [adobe.com].
confining javascript (Score:3)
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: (Score:2)
Other options not always an option (Score:5, Insightful)
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.
Re: (Score:2)
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 [---] "Axis of Evil" of insecure software.
That seems like an accurate, believable description of a common situation. I just wish I'd some time see someone *try to get out* of a lock-in situation like that. Or try to avoid creating more such situations. It has been well-known for decades that you can end up there, and yet organizations still plunge in, head first, all the time.
(Note that the lock-in isn't just about paying $$$ to the vendor indefinitely. It also means your data is cut off from the rest of the ecosystem; you can't benefit from in
Ditch acrobat (Score:2)
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.
Printing ? (Score:2)
Print then delete the file.
acrobat reader sanitized 100% (Score:5, Informative)
In the install tree find the file JSByteCodeWin.bin and rename it. Works for me.
Re: (Score:3)
PTSD (Score:2)
I think all the people commiting suicide at their Seattle office might be getting to them.
Their Seattle office is right under the Aurora bridge, popular with jumpers...
Summary (Score:4, Informative)
I did not know it was possible to detect javascript in a PDF, and I think this is possibly a better approach than a full rewrite (btw: I found this python script: http://blog.didierstevens.com/programs/pdf-tools/ [didierstevens.com] ) So instead of rewriting every PDF, you just choose to delete any PDF attachments that are detected with JavaScript. I assume this will then not break any legitimate PDFs that have comments or forms, etc? It will need testing, I guess.
The mail relay can then be configured to detect and delete any javascript-containing PDFs and allow everything else through (including encrypted, which is more likely to be legit than not). Once again, this is not the only protection against this malicious code, but just one facet. I found some recent exploits that don't need javascript at all, so it seems the safest, yet most likely to make you hated, approach is to rewrite the PDF completely or not allow PDFs at all.
Ghostscript (Score:5, Informative)
I use Ghostscript when attempting to compress a "bloated" PDF (such as generated by Xsane). The input is a PDF, output is a PDF:
# Use ghostscript to re-write the PDF
gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=new.pdf old.pdf
Also handy to combine multiple PDFs into a single document, or copy out certain pages from a PDF:
# Combine PDFs
gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=combined.pdf 01.pdf 02.pdf 03.pdf
# Copy pages 3 & 4 from an existing PDF
gs -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -dFirstPage=3 -dLastPage=4 -sOutputFile=new.pdf current.pdf
CCC (Score:4, Interesting)
There's an interesting talk from Chaos Communication Camp 2011 about making a verified PDF scanner in the Coq proof assistant: http://www.youtube.com/watch?v=CmPw7eo3nQI [youtube.com]
Re: (Score:2)
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: (Score:2)
Re:Why are you doing this? (Score:5, Informative)
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: (Score:2)
Re: (Score:2)
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...
Re: (Score:2)
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: (Score:2)
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 b
Re: (Score:2)
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: (Score:2)
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 i
Re: (Score:3)
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.
I believe the entire point of the original submission was likely to troll this fact; as soon as he/she said that they wanted to do it while transitting a mail gateway, it was either a request for PDF encryption cracking or a troll against Adobe locking down documents in this fashion.
I've personally railed against government agencies being in violation of the Americans with Disabilities Act for putting up PDF forms that have to be filled in by loading them into Adobe products, but until someone who has been
Re: (Score:2)
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.
Encrypted PDFs can be broken, quite quickly - a quick search pulled up some tools - one of which I had to use a while back for work [1]. I decrypted about 40k documents in less than a day with GuaPDF, with only about 300 or so that couldn't be cracked - 99% success rate. Combine with the JS detection method noted in another comment [2], and you can still tell if there's a dangerous PDF most of the time.
If you need to protect your populace (i.e., at the mail server level), combining the two above and eith
Re: (Score:2)
If somebody is in charge of filtering policy on a mail server that's carrying such traffic the answer is nearly always yes.
Re:Change configuration (Score:4, Insightful)
And be sure to double-check that the next update doesn't revert those settings on you...
Re:Take A Step Back (Score:4, Insightful)
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: (Score:2)
Postscript is a turing complete language, it has even more scope for including malicious code than pdf does.
Incidentally there are also subset versions of the pdf format which don't include stupid features like javascript.
Re: (Score:3)
Invoice: Text file, HTML, spreadsheet, etc.
Pixel-accurate, in a single file, with embedded vector fonts and raster images? What kind of text file is that?
Contract: Rich Text file (signed with GPG/PGP), Text file (signed with GPG/PGP), HTML (with SHA hash stored elsewhere), markdown (signed with GPG/PGP), ODF, or even Doc or Docx.
Doc and Docx are the likeliest candidates, at least because most documents are prepared in them. However these files are not pixel-accurate, and they do not lock the content,
Re: (Score:2)
Re: (Score:2)
So you make it inconvenient for your employees to do their jobs, which will make some potentially good employees walk and reduce the efficiency of those who remain. Technology is supposed to improve the efficiency of workers, otherwise why bother using it at all? It's very hard to include working exploit code on a piece of paper.
While i agree attachments are often misused, and i utterly detest companies that attach a bunch of images to every email they send out, all you can really do is avoid doing such stu