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

Comments

Re:Why

[jshare]

Well, you can run into trouble if you try to scan this zip file.

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:Set up a sandbox.

[dfgdfgdfg]

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.

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:Safe file exchange should be a *feature*!

[Muggins the Mad]

Welcome to .NET - I know I'll be flamed, but this is what Microsoft's new technology is about

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:OS

[sql*kitten]

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?

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 .sh file, then the problem would also exist on Linux.

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

[Zork the Almighty]

Don't files on Linux default to non-executable ? Your point is well taken though. And I would say it's the Linux distro's fault if it enabled all these useless services by default and left me vunerable.

Re:You get a virii scanner that can deal with zip.

[Jucius Maximus]

"Given that most users love to download crap via hotmail etc. , lets hope you have a virus scanner on their PC too."

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.

They were lucky...

[Dthoma]

...that no one uploaded a zip bomb. For the uninitiated, that's where you make a huge file or series of files containing nothing but a single character (e.g. a null character) repeated millions/billions of times over and then compressed. Since such perfectly repetitive data compresses so well, it's easy to upload the resulting small file (on the order of a few dozen kilobytes) and wait for the server to get thrown off unzipping it.

Re:OS

[alangmead]

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 the authors stated

The "application" Content-Type is to be used for data which do not fit in any of the other categories, and particularly for data to be processed by mail-based uses of application programs. This is information which must be processed by an application before it is viewable or usable to a user. Expected uses for Content-Type application include mail- based file transfer, spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) email. (The latter, in particular, can pose security problems which should be understood by implementors, and are considered in detail in the discussion of the application/PostScript content-type.)

and

Security considerations: This type is intended for the transmission of data to be interpreted by locally-installed programs. If used, for example, to transmit executable binary programs or programs in general-purpose interpreted languages, such as LISP programs or shell scripts, severe security problems could result. In general, authors of mail-reading agents are cautioned against giving their systems the power to execute mail-based application data without carefully considering the security implications. While it is certainly possible to define safe application formats and even safe interpreters for unsafe formats, each interpreter should be evaluated separately for possible security problems.

Just 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.

How to break zip-file scanners

[Safety Cap]

The problem with ZFSs is that they can be broken easily. Here's one way to do it:

1. 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:
   

   echo aaaaa > punkd.txt
   
   for /l %%b in (0,1,11) do copy /y punkd.txt + punkd.txt punkd1.txt && copy /y punkd1.txt + punkd1.txt punkd.txt
   
   del punkd.txt

   (note that the second line is long and may wrap on your display)
2. Run the batch and copy off "punkd1.txt" to another name.
3. Make several copies of the file.
4. 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.
5. Deliver the package to your victim.

When the ZFS tries to unpack the files to scan them, it blows its swap space.