Slashdot Mirror


To Allow or Not Allow E-Mail Attachments?

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?"

21 of 197 comments (clear)

  1. OS by Johnny+Mnemonic · · 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?

    --

    --
    $tar -xvf .sig.tar
  2. Safe file exchange should be a *feature*! by Muggins+the+Mad · · Score: 4, Insightful
    If you do block ZIP files, how do you give the people who need to sends files the ability to do so?

    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

    1. Re:Safe file exchange should be a *feature*! by Muggins+the+Mad · · Score: 3, Insightful
      Actually, the virus he talks about only works through social engineering. You have to manually open the zip file and click the .exe file.

      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 Mad
    2. Re:Safe file exchange should be a *feature*! by Muggins+the+Mad · · Score: 2, Insightful
      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).


      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 their little evil hearts, actually got something right with the Java OS idea. (lots of other things wrong, but the security architecture was good).



      We *really* need projects like SELinux, RSBAC, even LIDS to reach fruition so we can start building decent sandboxes. The higher end commercial UNIXen seem to be doing good things with ACLs and better privilege seperation, but we can't all run those. :)


      And I mean built into common dists, not as some obscure kernel patch that breaks all your daemons :)


      - Muggins the Mad
    3. Re:Safe file exchange should be a *feature*! by joto · · Score: 3, Insightful
      Ok, to bring another level to it. Why is running an unknown executable dangerous?

      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.

    4. Re:Safe file exchange should be a *feature*! by Muggins+the+Mad · · Score: 2, Insightful
      UNIX permissions do not allow random writing, deleting, spamming whatever.

      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
    5. Re:Safe file exchange should be a *feature*! by Muggins+the+Mad · · Score: 2, Insightful
      Ok, to bring another level to it. Why is running an unknown executable dangerous?
      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.

      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 having direct access to hardware and force them to go through the OS.

      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 checks in there.

      Raw machine code executables are bad because they aren't cross platform, but I don't see why they are necessarily a security issue under a secure OS

      People need to be trained to only open safe file-types they get from untrusted sources.

      Only in the current climate of insecure operating systems. I *want* people to be able to send me cute little applications or games, or interactive data files. Why should we be limited in what we can do because people are so used to the inadequacies of current mass products when there isn't really a technical limitation at all?

      - Muggins the Mad
    6. Re:Safe file exchange should be a *feature*! by matastas · · Score: 2, Insightful

      From a business standpoint, this is a potentially disasterous attitude. Observe:

      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 merger is negatively affected. CEO kindly asks who made decision to block file attatchements. Admin is fired.

      You said it yourself: this is a decision that needs to made based on business needs. Your proposed solution is black and white; you forgot the infinite shades of gray. Outsourced virus scanning, user education, various options at the desktop...it goes on. Don't cripple a key feature of modern email, and thus workflow, because the technology presents some hurdles, or possibly is only 80%. That's why we all get paid.

  3. Who said you had to filter it? by NeuralNet03 · · Score: 4, Insightful

    I think that if a user opens an attachment from a random source, that came with no explanation, with a funky name like the ones in the write-up (see article link), then that's their own fault.

    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.

    1. Re:Who said you had to filter it? by Blkdeath · · Score: 2, 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.

      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 earlier."

      How does your proposed seminar cover this situation? Since most Windows maladies lately attack Outlook (Express) directly, and specifically its address book, the notion of "attachments from unknown people" or attachments that come from "a random source" are no longer valid. Attachments are coming from friends, family, colleagues, and even Microsoft Technical Support.

      Malicious users have become so crafty that the entire notion of e-mail attachments and their utility has to be re-examined.

      Incidentally, Microsoft's new security poilcy WRT attachments in Outlook Express has made the situation worse, not better. They've blocked so many attachments the functionality is useless to users, so they're resorting to disabling attachment blocking entirely, putting them right back at square one.

      --
      BD Phone Home!

      Shameless plug. Like you weren't expecting it.

  4. attachments are bad by Feztaa · · Score: 4, Insightful

    IMHO, email is not a file transfer medium; sure you can send little things with it, but it's just not useful for any real kinds of file transfer.

    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.

    1. Re:attachments are bad by klui · · Score: 2, Insightful

      You'd need to retrain everyone who use email to stop using attachments. This won't happen, since they've already tasted attachments' convenience. There are those who are so clueless that they would blindly send 10MB worth of shit uncompressed to an entire company's distribution list without a second thought. The sad thing is they don't realize: sending 10MB is bad in the first place; broadcasting to everyone in a company is not efficient (you'd eventually get bozos replying "Please don't give me this file!!!"/"Take me off this distribution list!!!!"/"Please don't reply to all!!!!!"); sending MS Word/Excel/what-have-you uncompressed is wasteful.

      Someone in my company insists on sending some document to a distribution list each week--uncompressed--and not have a central repository for access via http/ftp. Most people are lazy and it's much easier to drag and drop w/out creating that zip file. I once sent a link via MS Outlook to an MS share that had spaces in the path (I don't have permission to change the names of those directories that had spaces). I later found out that this same person was clicking on the link as is (even though if you look at the link, its coloring was blue for a part of the path and black the other) and had just assumed that I typed/pasted it in wrong. This behavior told me that said individual has no clue how URLs/links work/look like in Outlook--just wanted to double-click on an attachment. And I was asked to attach my original document rather than providing a link.

  5. Set up a sandbox. by Flying-Cow-Man · · Score: 4, Insightful

    This is an important point. Why should running an executable be dangerous at all? is it really that difficult to set up a sandbox (a la the JVM) for users to run untrusted executables in? There may be some more hassle involved, but it could be implemented fairly transparently.

    --
    Don't knock HTML email. It makes my life easier, since I /don't/ _have_ to "find" STUPID *workarounds
    1. Re:Set up a sandbox. by Flying-Cow-Man · · Score: 4, Insightful

      This would only protect other users from the effects of an executable. I'm not sure about you, but I consider my home directory to be far more valuable then the rest of the installation, which I could easily recreate within an hour.

      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.

      --
      Don't knock HTML email. It makes my life easier, since I /don't/ _have_ to "find" STUPID *workarounds
    2. Re:Set up a sandbox. by Anonymous Coward · · Score: 1, Insightful

      For a quick toned-down impression of what you're asking for, set Internet Explorer to ask for permission when a page wants to execute a script or set a cookie.

  6. Re:Or... by bellings · · Score: 2, Insightful

    That sounds cool. Can you recommend a computer that wont get email trojans? An XBox, or perhaps an old Atari 2600?

    --
    Slashdot is jumping the shark. I'm just driving the boat.
  7. Re:Why by crisco · · Score: 3, Insightful
    so basically that could be used as a DOS against someone running a virus scanner on the email gateway?

    evil

    Are all of the virus scanners going to recursively extract all those zip files?

    --

    Bleh!

  8. What you really should be doing by PD · · Score: 4, Insightful

    You should make sure that your bounce messages go to the right place. I've received countless messages informing me that my attachment was stripped because it contains the Sobig virus. The second thing you should do is to make sure that the full headers of the message get inserted into your bounce.

    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.

  9. Business Risk versus Security Risk by RedPhoenix · · Score: 5, Insightful

    This, and similar issues, have cropped up at a few of our customer sites over the years. There are situations where bringing in (documents/zip files/spreadsheets/etc.) are an essential part of making organisation function.

    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.

  10. Re:Here's abetter idea idea... by Black+Copter+Control · · Score: 2, Insightful
    Enable attachments. Disable Windows.

    That'll really cut down on your virus problems.

    --
    OS Software is like love: The best way to make it grow is to give it away.
  11. Automatic translation to open source could work by Animats · · Score: 3, Insightful
    The big problem is proprietary file formats. So how about a format-translation gateway? One based on components of OpenOffice. It would convert the proprietary formats that cause trouble (mostly .doc and .xls) into RTF or OpenOffice XML-based documents, then pass those on with a note.

    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.