To Allow or Not Allow E-Mail Attachments? 197
t0pper311 asks: "I work for a pretty large utility company in the midwest and of course, security is a big concern. We use Trend Micro as a mail gateway to basically scan for virii and strip off most attachments like executables or VB script. Now with the Sobig.E virus on the loose, we need to ask ourselves if we should be blocking ZIP files. We got lucky this time and were not effected, but what about next time? What are other companies doing? If you do block ZIP files, how do you give the people who need to sends files the ability to do so? Do you allow any attachments at all?"
You get a virii scanner that can deal with zip.. (Score:5, Informative)
Given that most users love to download crap via hotmail etc. , lets hope you have a virus scanner on their PC too.
Re:You get a virii scanner that can deal with zip. (Score:5, Informative)
Your point about not relying on any one point of access is well taken though - all entry points need to be protected in one way or another.
Re:You get a virii scanner that can deal with zip. (Score:5, Interesting)
That is true. At one company I worked (with several thousand employees) there was an virus outbreak every one or two weeks on the corporate network.
This reduced to once or twice per year after they blocked off hotmail, yahoo mail, lycos mail, ICQ, AIM, etc. And really, if you are smary enough to get around this an use a small webmail provider then you're smart enough to not download a virus as well.
How to break zip-file scanners (Score:4, Interesting)
- Create a 67 meg ASCII file with nothing but a single repeating character. Here's an three line command-line (DOS) batch file to do it:
- Run the batch and copy off "punkd1.txt" to another name.
- Make several copies of the file.
- Zip them all into your "package 'o death." Due to the simple structure of the file, it will zip down quite a bit (close to 99%) if you use maximum compression.
- Deliver the package to your victim.
When the ZFS tries to unpack the files to scan them, it blows its swap space.(note that the second line is long and may wrap on your display)
OS (Score:3, Insightful)
Why do you make so many accommodations for the failures of the OS? Isn't the OS supposed to work for you, instead of you working for it? How many features do you have to shut off before it's not worth the considerable cash you paid for it?
Re:OS (Score:5, Interesting)
Clearly you lack an understanding of the issue. This is nothing to do with OS. The issue is one of users running executables they are sent via email. If (insert your favourite Linux email package here) allowed a user to double-click an attached
Outlook was designed to be scripted so you could use it to build your own workflow . If you don't need this feature, switch it off! Complaining about exposed but unused functionality being abused is that same as complaining that it's Linux's fault of all the daemons are started at boot and someone roots you though BIND.
Re:OS (Score:4, Interesting)
Re:OS (Score:4, Interesting)
The part where the OS gets involved is when it uses the same mechanism to associate documents with their application as they do interpreted code with their interpreter.
MIME has a Content-Type mechanism to describe data. In the original MIME specification [ietf.org] the authors stated
andJust because the designers of outlook essentially ignored the data description features of MIME didn't mean they had to ignore the warnings of the dangers of executable content. There is no reason why a mail reader should associate a .sh file, or an application/x-shell-script file with a general purpose interpreter, and the people who invented MIME knew this and warned about it.
There is no good reason for a mail program to run hand executable content off to the OS or an interpreter.
Safe file exchange should be a *feature*! (Score:5, Insightful)
I think if people insist on running software that is vulnerable to these kinds of attacks then yes, you do need to stop these people using attachments completely.
If we do need to send files to each other as part of our business then surely that's a major feature that our application environment needs. If our chosen solution doesn't let us do that without an enormous amount of hassle and risk, then maybe it's time to make other tradeoffs and choose a client that does.
And if we have to choose between an email client with nice scheduling/calendaring and one that lets us receive file attachments safely, then that's a *decision* that must be made based on business needs. Which is more important to your task? Is there a way to have both? Will we accept the risk and hassle of virii to get nice calendaring, or will we use clumsier calendaring and have safe file attachments?
Only when people start making these conscious decisions en masse will we start seeing applications (including OS/hardware/whatever) that provide all the features we need to do our jobs.
The current climate of "how do we shore up the inadequacies of our chosen software?" isn't helping things improve.
Nice calendering *or* safe file attachments. Choose. If someone offers a product that does both. Cool. We all win.
- Muggins the Mad
Re:Safe file exchange should be a *feature*! (Score:5, Informative)
From what I can gather from the virus information, it's not an Outlook virus. It's a Windows virus that propogates through its own SMTP routines, harvesting email addresses from a variety of local files. In Outlook it requires the user to extract the executable and run it, just like any other mail client.
Re:Safe file exchange should be a *feature*! (Score:5, Informative)
Actually, the virus he talks about only works through social engineering. You have to manually open the zip file and click the .exe file.
Re:Safe file exchange should be a *feature*! (Score:4, Insightful)
Ok, to bring another level to it. Why is running an unknown executable dangerous?
It's pretty safe running unknown Java Applets in our browsers these days, barring the occasional VM bug. Why can't we run random executables without worrying that they'll delete everything/spam/etc.
Why the assumption that running a random executable is dangerous?
- Muggins the MadSet up a sandbox. (Score:4, Insightful)
Re:Set up a sandbox. (Score:3, Interesting)
Re:Set up a sandbox. (Score:4, Insightful)
A good VM would allow you to interact in a useful way with the application, without allowing it unauthorised access to your data.
A quick (though cumbersome) workaround would be to have another account on the machine within which any untrusted apps may be tested first. Though awkward, it does prove the concept.
Re:Set up a sandbox. (Score:5, Informative)
The chroot command should help.
Re:Set up a sandbox. (Score:2)
Last I checked, typing chroot into a command prompt on a Windows box resulted in a blank stare.
Re:Set up a sandbox. (Score:2)
Perhaps you're the only one which didn't notice GiMP telling the poster to get an operating system with real security. For the most part, the sandbox the poster was talking about can easily be implemented with common commands. Commands which set kernel enforcement of security procedures. They have been operational in various systems before Microsoft had ever heard of security. I was securing my Linux box while Win98 would allow any user or any program (including a virus) to do any nasty thing with the syste
Re:Set up a sandbox. (Score:2)
Re:Set up a sandbox. (Score:2)
Re:Set up a sandbox. (Score:2)
Yeah, it is called Unix.. Run it as a non-root user. The worst that happens is that that user's data is stolen or deleted (credit card numbers, etc)
So, even better, run it as a non-root user that has no permissions and no files, similar to the way most Internet-accessible daemons are run. Oh, and do it in a chroot jail in a temp directory that gets cleaned out after the execution.
Not a perfectly secure solution, since it would still be possible to write a worm that exploits some local holes to break o
Re:Set up a sandbox. (Score:4, Interesting)
Exactly! Files that are executed should always be executed in a sandbox, except if the reside in "/usr/bin" or other system directories. If the common file managers/ email client did that, there would be no problem sending exes per mail.
Someone should implement the following: A program "nobody" that executes a command line and traps all system calls. When the child process does a system call, it asks the user e.g. "The program wants to open a connection to c32x.com. Allow?". If the user answers "No", the system call just returns -1. You could invoke it just like "nice" or "nohup". That should solve the email-attachment problem. Programs like "strace" already trap system calls, so this must be possible.
Re:Set up a sandbox. (Score:2)
Re:Safe file exchange should be a *feature*! (Score:2)
Windows allows executables to work on any file. And Windows scripting allows scripts and exes to find
Look, security has been afterthought with MS every time. NTFS is a little more protected but not much.
Look up permissions on Unix and even AmigaOS (which had 32-bit preemptive multitasking 10 years before win95 and almost 20 years before MacOS X).
Re:Safe file exchange should be a *feature*! (Score:3, Insightful)
Unfortunately UNIX permissions are still woefully out of date. It doesn't really matter these days that malware can't reformat your drive. It can still send all your files out on the 'net, send a couple of million spam, and delete all your work.
Sun, bless t
Re:Safe file exchange should be a *feature*! (Score:2)
Re:Safe file exchange should be a *feature*! (Score:3, Insightful)
Um, yes they do.
Pretty much any program can read your mail settings from .mutt or .netscape or .whatever, pick a bunch of juicy .doc and .jpg files from your home directory and email them to a few million people. Then delete all the files in your home dir.
Projects like SELinux can pretty much solve this, but until they're integrated in the major distros, we're a lot more vulnerable than we like to believe.
- Muggins the Mad
Re:Safe file exchange should be a *feature*! (Score:2)
Re:Safe file exchange should be a *feature*! (Score:3, Interesting)
Re:Safe file exchange should be a *feature*! (Score:4, Interesting)
Yes, and god forbid they actually get it right. The free software world needs to snap out of it's smug "UNIX is secure" stance and do something to bring it into this millenium. I want to run executables from random places. As part of my job I actually need to. I don't currently have an OS where I can do that. I would hate for the first one that lets me to be from MS.
- Muggins the Mad
Re:Safe file exchange should be a *feature*! (Score:4, Insightful)
Because at some point, you need something that actually uses raw machine code, unless you want a very limited system. Not having this option, and having to run everything through a VM is not a very good option from either a performance or functionality standpoint.
I'm not saying I'm againt secure byte-code interpreted environments, such as Java. Actually, I am all for it, but sometimes you need to do things a bit more low-level than the Java API allows, and that means you'll have to allow executables.
Still, there is a lot that could potentially be done to limit the harm you can do with executables. You can sandbox them in various ways, from intercepting system-calls and let some access-level checker see if you have the right privileges (sometimes called capabilities), to running in a different VM (such as user-space linux), to full emulation (bochs). Whether such security measures should be on by default, and only "trusted" executables should be allowed to do what they do now, or special actions needs to be performed by users to run "untrusted" ones is of course up to debate.
My point is that the problem is only halfways technical. Adding additional security measures can never protect stupid users from doing stupid things. If the e-mail had said: "this app needs to be 'trusted' before you run it, please enable that before clicking on it", you can be sure some users would do that.
The problem, if anything, is more of a cultural issue than a technical one. In windows, users have become accustomed to run random binaries from unknown sources, and the environment has as a result been set up to make it easy. Under unix, you would generally be skeptical of running a binary from someone you don't know or trust, and the environment has generally been set up to make it somewhat harder. Unfortunately, the trend seems to go in windows direction (even on unix). End-users are rarely supportive of security features that make their job harder, even if it is more secure.
Running an unknown executable is always a bad idea. People need to be trained to only open safe file-types they get from untrusted sources.
Re:Safe file exchange should be a *feature*! (Score:3, Insightful)
There's no reason raw machine code needs to be dangerous at all. Modern computers (even PCs) have decent memory protection that'll stop user programs from havi
Re:Safe file exchange should be a *feature*! (Score:3, Interesting)
Yes, this was the first option I mentioned.
The OS can decide what the user program is allowed to do. Whether it's opening network connections, allocating more memory, writing to screen or file, it *already* goes through the OS anyway. So it's not much of a step to put a few security
Re:Safe file exchange should be a *feature*! (Score:2)
Because Java stuff runs in a sandbox. If you are logged in as Administrator and run a java applet in your browser, it can only wreak havoc if you give it permission or it exploits a bug that you forgot to patch.
If you run a random .exe file as Administrator, it doesn't need permission from you to hose the
Re:Safe file exchange should be a *feature*! (Score:2)
For precisely the same reasons as why should walking down the street minding your own business be dangerous? Many attacks and muggings however are carried out daily against people for doing just this.
Re:Safe file exchange should be a *feature*! (Score:2)
Because the OS has no way of knowing whether the random executable trying to format the hard disk has been run accidentally or deliberately.
Re:Safe file exchange should be a *feature*! (Score:2)
It's pretty safe running unknown Java Applets in our browsers these days, barring the occasional VM bug. Why can't we run random executables without worrying that they'll delete everything/spam/etc.
Why the assumption that running a random executable is dangerous?
Defining what an app is allowed to do is pretty tricky. That's especially true if you want to be able to bubble up decisions to the user.
Suppose that somebody send
Re:Safe file exchange should be a *feature*! (Score:2)
Kmail has a good balance between previewing content and safety IMHO, but then I am happy to see raw HTML by default.
Re:Safe file exchange should be a *feature*! (Score:3, Insightful)
1. Outbreak of viruses. Admin makes decision to block file attatchments.
2. M&A activity occurs two months later. CEO requests data from investment banker, who sends it in ZIP file.
3. File attatchment is blocked. Confusion insues.
BEST CASE: CEO finally gets file w/trickery and support from IS, and asks feature to be turned back on, or supported for limited group.
WORST CASE: Bad Things happen as a result of delay, and mer
Why (Score:3, Informative)
Re:Why (Score:5, Interesting)
I forget the exact stats, but it decompresses out about 7 levels deep, 16 files per level, and 4gig files at the last level. So, that's a lot of unzipping your virusscanner would be doing.
Granted, you could probably give it a checksum for this file in particular, but there are always variations on the theme.
Re:Why (Score:4, Insightful)
evil
Are all of the virus scanners going to recursively extract all those zip files?
Re:Why (Score:2)
Re:Why (Score:2)
Strangely fast.
Re:Why (Score:2)
Re:Why (Score:2)
WARNING!!! (Score:2)
If you're on a network where someone (other than you) gets an alert if your virus scanner detects something, *do not* download that file because it is identified as a 'zipcrash' trojan.
Might be a stupid Q, but... (Score:2)
Re:Might be a stupid Q, but... (Score:2)
I think the 4gig files are actually just 4gigs of Nulls, so that's obviously very compressible.
Or... (Score:3, Interesting)
Re:Or... (Score:3, Insightful)
Re:Or... (Score:2)
Yes, of course I can.
And the fact that you're posting in this forum at all should indicate that you are (or should be) just as aware as I am as to what those OSs are.
Re:Or... (Score:2)
Re:Or... (Score:2, Interesting)
Who said you had to filter it? (Score:4, Insightful)
Filtering out legitimate attachments is not very good policy to protect against virii. You'd be -much- better off spending a few minutes educating employees in a "Virus Prevention" seminar or something. Show them that opening emails like that is not intelligent, and that way, it's not as much of a problem.
Re:Who said you had to filter it? (Score:3, Insightful)
Picture this;
User receives attachments from a colleage sometimes as often as a dozen times a day. An e-mail comes in from this user with an attachment described breifly as "The file we discussed earli
Re:Who said you had to filter it? (Score:3, Informative)
Why don't Microsoft display all attachments that would be executed in a unique way or have a dialog come up confirming execution? Or display the whole filename and not hide any file types?
I agree: new Outlook Express default policy is even more brain dead. One cannot even download and sa
Re:Who said you had to filter it? (Score:2)
Similar issue happened like 10 years ago (Score:5, Informative)
They were lucky... (Score:5, Interesting)
Re: (Score:3, Interesting)
Just block malicious files like .pif, .exe, .vbs.. (Score:4, Informative)
Just block the potentially incompatible ones (Score:2)
I've set up mailing lists which contain large numbers of non-expert users so I set an automated rejection + message of anything with incoming attachments. This not only stops the MSTDs dead, but also makes the size of the archive smaller, and allows the archive to be fully searchable. From the user side, it eliminates crowded inboxes (many web-mail clients have small limits) and, for the novices, it eliminates the
Better Scanner... (Score:3, Interesting)
er, why not use a proper AV product? :-) (Score:3, Interesting)
That said, I was surprised to find one of the largest employers in MA doesn't have *any* AV protection on their Exchange servers, and had quite a bit of downtime as a result. So I guess AV on mail servers aren't as commonsensical as I thought...
Running Exchange is bad enough, but do-able. To run Exchange *without* decent, up-to-date AV software is just incompetent.
attachments are bad (Score:5, Insightful)
Personally, I think you should set up an FTP that is open anonymously to everybody in your company, and then disable attachments so that people have to upload to the ftp, then email the link around.
Re:attachments are bad (Score:2, Informative)
The problem in this case is that some viruses don't actually need email to propogate. This particular one just needs someone to open it and run it. Doesn't matter if it came in via FTP, Email, or Kazaa.
- Muggins the MadRe:attachments are bad (Score:3, Insightful)
Re:attachments are bad (Score:2)
Three clicks - and an you end up with an open blank email message with your file attached. groovy.
Re:attachments are bad (Score:2)
That's exactly what I was getting at. Email isn't designed for file transfer, it's designed for sending short ASCII text messages
Re:attachments are bad (Score:2)
Re:attachments are bad (Score:2)
In that case, set up something similar, except with a different protocol (bittorrent? Less practical for small files. maybe just SMB or NFS or something).
What if (Score:2, Interesting)
the guest accounts could expire after a time frame, or a number of uses, or whatever.
Altp.
I think we check inside zip files (Score:3, Interesting)
the 'affective disorder' virus (Score:5, Funny)
This cunning virus sniffs all your outgoing email and replaces 'affect' with 'effect' and vice versa. So while we know that you wrote "We got lucky this time and were not affected...", this malicious virus made it appear on slashdot as though you are 'affectively disordered'.
Virii (Score:2)
(C'mon, "viri" I can understand, but who's the knucklehead that thought up "virii", and why does this spurious plural spread as if it were itself a virus?)
This is not hard (Score:3, Informative)
Re:This is not hard (Score:2)
The idea here is that by unilaterally blocking .vbs, for example, you're immune to new .vbs viruses which the scanner engine doesn't yet know about.
When sobig.E hit the world, scanners didn't know about it. Because it was in a zip file, it sailed right past a lot of precautionary attachment stripping.
Yes, once it was incorporated into virus defs, compressed attachment scanning will find it. But the question here is if .zip files should be unilaterally blocked to prevent the next .vbs virus from sneaki
Re:This is not hard (Score:3, Funny)
In a perfect world, yes. But I've personally said to co-workers 'If you get a message with a subject of ILOVEYOU, do NOT open it!' and they'll say "Ok, I won't. Hey, I've got mail...oooh, the secretary loves me! *click click*'
What you really should be doing (Score:4, Insightful)
The funny thing is that I run only Linux on my domain, and I never e-mailed those people anything. It's very unlikely that Sobig can run on Linux. And I can't do anything about it because I don't have any headers to track down the source of the mails. Nobody's answered my requests for them either.
Re:What you really should be doing (Score:2)
Actually, on virus reciept, notify the recipient, NOT the sender, as the "sender" rarely is the sender. You often wind up spamming some poor bastard who's email address got picked at random.
Train your userii (Score:2, Funny)
Not all zip files (Score:5, Informative)
in my main.cf created a line that says
body_checks = pcre:/etc/postfix/extensions
then created a file called extensions that looks like this:
The first line (yes it's all one line) blocks all executable files from entering the server. The second line block the only version of sobig that we received. Actually we received 2 modifications...one attachment was called your_details.zip, and the other was 'your_details.zip the ' allowed it to get around the filter, hence the wildcard.
The key is, to inform your users over and voer not to open things from people they don't know or aren't expecting. If you start blocking zip's you might as well block all attachments.
Re:Not all zip files (Score:2)
Business Risk versus Security Risk (Score:5, Insightful)
Whilst you can implement technical countermeasures to reduce your security risk somewhat, such as installing virus checkers that are able to unzip/unarj/unrar, keeping virus signature definitions up to date, quarantine incoming attachments.. etc, you really need to compare your security risk profile, with the business risk associated with NOT receiving these attachments.
This would normally be the function of your organisational risk assessment - it would compare the likely harm of virus infection, against the loss of capability as a result of not receiving the documents/zip files in question.
Which way you go, really depends on the threat/risk/harm/countermeasure equasion, which is unique to your organisation. However, a quick 'cheat' check:
* How badly is it going to hurt your organisation overall, if attachments don't come in?
* Do you have the resources to quickly clean up a virus attack if one makes it through?
- If you're a small organisation, with adequate IT staff numbers, and receiving attachments is pretty essential to your normal business... it's probably worth allowing things through.
- If your IT staff numbers are limited such that a virus attack would be a major cleanup effort, or attachments aren't all that critical, then block them, or quarantine them by redirecting them to technically literate help-desk users (who can forward them internally after checking them out).
However, make sure that you make it relatively painless for users to get their files. If you're really anal about things, they'll just open up a hotmail/yahoo/whatever account, ask people to send attachements there instead, and download just like a normal web link.
Red.
Use some Human Engineering (Score:3, Informative)
If an email with a forbidden attachment type is received, bounce it back to the sender with a "Sorry, no go" message UNLESS it has a matching flag in the subject line.
So, to send a friend of mine a picture, I need to include [JPG] in the subject line, else it will bounce.
Simple, easy, and proof against viri because YOU choose the flag.
In your case, set it up to require [FUBAR] in the subject line to let a zip file through.
Sorry though, I don't know the software package they use.
Renattach (Score:2)
We use RenAttach and I added ZIP files to its list of 'bad' files last week as a precaution.
If you aren't familiar with it, RenAttach processes each email and compares the file extension of each email attachment against a list of "bad" extenstions you've configured. Any files with bad extenstions are renamed: "yourfile.exe" becomes "yourfile_exe.xxx".
This prevents auto-running executable viruses from damaging anything, but still leaves the user in control so they can exchange data. This would not work in
Some experience (Score:2)
Re:Some experience (Score:2)
Note that a staffer had to set this up; an outsider could not make the arrangements. Internal distribution to the intended recipient was via floppy or CD, who had to sign for it.
Strip Files Not Related To Work (Score:2)
I worked at a security-conscious place a few years ago. Executables, zip files and the like were stripped off incoming mail.
Our Company (Score:2)
Multi-Level Solution (Score:5, Informative)
Here's what we do:
1. Use Symantec Antivirus for SMTP Gateways 3.1. Blocks spam by subject, sender, multiple RBLs and heuristic antispam and has whitelist support. Scans for viruses and attachments can be deleted by filename with wildcards. I block anything that is executable in a Windows environment (since we use Windows, Exchange and Outlook -- no flames, please). Any file deleted gets a .txt file added to the message stating that <filename> is not allowed for security reasons. This means that if anyone needs to send a .exe, .cmd, .bat, .vb?, .cpl, .dll, and a number of others must first call so I can temporarily disable the deletion.
2. Use another company's antivirus on the mail servers. We use Sybari with multiple scan engines. This saved us this past week when the new FortNight.E managed to get past SAV for SMTP because it didn't detect it yet and it was essentially a script embedded in an html. (I'd love to strip them, too, but too many legitimate emails come through as html.) Sybari caught it after Symantec missed it.
3. Use another antivirus package for clients and servers. We use SAV Corporate edition with a master server setup so that one server d/l's updates from Symantec nightly or when I force it. Each remote location's server d/l's from that server nightly or when I force it. Each workstation d/l's from their location's server every 4 hours.
Since starting this practice, we've had a total of 2 viruses make it into our network. One was on a laptop that, for some strange reason never got antivirus installed and it was infected at the user's home. The virus never got further than that, but it took a while to discover where the virus alerts were coming from when it attempted to infect other machines. The other one had a corrupt install of the desktop antivirus and the end user didn't let us know that something didn't look right on his client. He then fell for the e-card virus (Go to this URL to download the greeting card X sent you.). Again, never got further than this one workstation. This is all the infections we've seen in over 2 years. Not bad for a 1500 user network.
really depends... (Score:2)
I don't normally get attachements as zip's but I have had to once or twice. If our company blocked zip files I would have never been able to debug the zipped core file one of our clients sent to me.
I think the real solution is maybe to use a 'quarantine' system. Where attachements can be held instead of blocked. Also make sure that you have a virsu scanner on
Digital signatures (Score:3, Interesting)
Automatic translation to open source could work (Score:4, Insightful)
Yes, sometimes translation will be disappointing, but you probably didn't need the formatting junk anyway. Besides, once it's in an OpenOffice format, you can file it in a system with a search engine.
Google ought to sell something like this as a product, since they already do most of those translations.
Re:For heavens sake... (Score:2)
Re:Here's abetter idea idea... (Score:3, Insightful)
That'll really cut down on your virus problems.
Re:Grammar police! (Score:2)
Re:Grammar police! (Score:2)
English is partially derived from Latin (and several other languages) and the plural of "virus" is indeed "virii", just as the singular form of "data" is "datum".
However, we live in a lazy, ignorant age - how many people even know that the singular form of "dice" is "die"? - and people often just add an "s" or "es" on the end of a word to pluralise it.
Just because you've seen the plural of "virus" spelt as "viruses" frequently
Re:Grammar police! (Score:2)
You are correct re "data," wrong re "virus." If the plural of "virus" in Latin was indeed "virii," I'd be fighting the good fight right along side you (I'm a big Latin and Roman-phile), but it's just wrong. "Virii" is not a word in any language, living or dead.
If you really want to get all technical, the strict plural of "virus" in Roman times