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?"
You could just let everyone catch every virus going for a few months, then offer them a real computer that doesn't get viruses. I wonder how many people would get the message.
Get a better scanner. I can't recommend Sybari's Antigen enough. It uses multiple virus scanner engines and has great filter support. It also opens up archive files and scans inside of them.
We use Symantec for Microsoft Exchange. It'll scan and clean files within zip files. SoBig.E has not been a problem for us (aside from the fact that we're running MS Exchange, of course).
;-p
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.
what if you choose to block email attachments completely, could you set up a respository on a computer. Have people drop attachments there, and as they finish their uploads scan them for viruses before making them visable for people to download. People could log in with their email addresses (on your side), and there could be guest accounts generated for people on the outside to get files in and out.
the guest accounts could expire after a time frame, or a number of uses, or whatever.
Altp.
From memory, MailScanner (ours uses the F-Secure engine) looks inside zip files. No biggy.
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)
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.
Welcome to .NET - I know I'll be flamed, but this is what Microsoft's new technology is about: bringing Java-like security to every application (Microsoft calls it "Managed" code).
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.
-- 1.e4 c6 2.d4 d5 3.Sc3 de4: 4.Se4: Sd7 5.Sg5 Sgf6 6.Ld3 e6 7.S1f3 h6 8.Se6:
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
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?
.sh file, then the problem would also exist on Linux.
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.
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.
In Soviet America the banks rob you!
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 checks in there.
Putting some checks there is not hard. Making it useful is hard. At the level of system calls, it is very hard to say what a program should be allowed to do in a way that would be useful for an end-user. Let's take a simple example: if you grant it access to the windowing system, how would you limit it to e.g. not controlling other applications through synthetic button and key events?
There is a reason we don't have this kind of security today. It is very hard to get right. Only with a higher-level security architecture, such as java, is it possible to make useful checks about what a program is allowed to do, and what it is not allowed to do. If it is at all possible at the level of system calls, it would be very hard to control in an intuitive manner.
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
Trouble is, there is no such secure OSes that are anywhere close to usable. But there is a lot of research going on in this area. In 10 years, maybe someone will make one of those research OSes into something close to useful. Personally, I find it unlikely, however. There is always a tradeoff between speed, flexibility, and security. Raw binaries is one end of the spectrum, and I don't think they are going away. But there is nifty research going into things like typed assembly languages, etc, and I may be proven wrong (at least I hope so).
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?
Because, there really isn't any realistic alternatives. Any mainstream OS is as vulnerable to the same kind of attack. There are two reasons this doesn't happen however: First; writing effective email-viruses for other platforms than windows is harder, because everyone uses different setups, and different mailclients. Secondly; Their users are generally more knowledgeable. But none of these reasons is technical.
If you want to exchange cute games and toys, send them as java applets, or flash swf-files, or whatever you feel would be reasonably secure.
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.
...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.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
Digital signatures verify the authenticity of the email, but come in as an attachment. Stripping these off is counter to your intent, maintaining security.
Can You Say Linux? I Knew That You Could.
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
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.
- 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)
Yeah, right.