Secure Coding mailing list archives

Hypothetical design question


From: "Kenneth R. van Wyk" <Ken () KRvW com>
Date: Wed, 28 Jan 2004 01:20:47 +0000

It's been a quiet day here on SC-L -- most likely, many of us are busy 
blocking or deleting copies of the mydoom worm that's floating around...

So here's a hypothetical but topical situation to consider.  Say you're fed up 
with the email client that's installed throughout your company because it 
seems to provide little more than a virus/worm petri dish.  So, you decide to 
design (yet another) alternative email client that will help alleviate at 
least some of the problems in the current one.  However, you realize that 
there's an uphill challenge -- like trying to put whipped cream back into a 
can, the user community has grown very fond of some of the very features that 
viruses and worms thrive on (e.g., file attachments that can be executed with 
a single/double click of a mouse) and you're going to pretty much be forced 
to somehow design something that keeps the users happy as well as improves 
the state of email security.  (Note that I am NOT referring to spam email; 
I'm only talking about email borne outbound viruses and worms.)

Can it be done?  What sort of design features would you put into the 
application to help prevent the system from being used to propagate viruses 
-- e.g., compartmentalizing or sandboxing the execution of attachments such 
that they have no network or file resources?  What sort of design/feature 
trade-offs would you think need to be made?

In other words, could an email client be designed and implemented that would 
satisfy both the users and the security requirements?  Or, is the problem too 
difficult without sacrificing some functionality?

Oh, and FWIW, when single-click executable attachments first started appearing 
in email clients, I vividly recall several people in the anti-virus community 
claiming that the "house of cards" would come tumbling down.  I think that 
that was something like 10 years ago...

Cheers,

Ken van Wyk
-- 
KRvW Associates, LLC
http://www.KRvW.com








Current thread: