RE: Hypothetical design question

["Shea, Brian A" <Brian.A.Shea () bankofamerica com>]

For what it's worth, here is the 2 cents or so I'd like to throw in.

First some assumptions.
1)  Coding a secure mail client is not a solution by itself because other factors weigh in too heavily to be ignored.  
OS Security and user security context have been discussed in other replies, and they will effect the ability to manage 
this issue.  The mail client is simply one factor in the equation, Defense in Depth is key to addressing this.
2)  One man's bane is another man's blessing.  Not every usage scenario that fits me is one that is needed or even 
desired by someone else.  Similarly some things I want eradicated may in fact be desired by others.  Specifically home 
users vs corporate users have very different usage profiles and may need different rules for handling the "attachment 
issue".
3)  Out of desperation more then desire, the solutions I use tend to cater to the least common denominator, expecting 
that a real power user or technically savvy user can find the manual and figure out how to configure it the way they 
want.  The default is locked down and secure so the non-savvy users can not worry about it and still use the tool.

Having said that, here is my initial shot at some design highlights that I'd want to see to address this issue.

Secure OS as a base - The Operating System beneath the mail client MUST be secured to protect the system and sensitive 
files from tampering to the degree it can.  Non-administrative contexts should be restricted from altering important 
system files, registry data, etc.  Should be standard practice but worth mentioning.

Non-administrative user context - The context used to read mail, send mail, or deal with attachments initially should 
be a non-privileged user context.  This should be enforced by the mail client if an admin logs on and tries to read 
mail by "shedding" extra privileges at execution time from the Mail Client process token.  This might still be 
vulnerable to RevertToSelf() attacks, but it is a reasonable first step IMO.

No HTML Mail - Inbound messages should have all "dangerous" tags removed if HTML formatting is allowed at all.  SCRIPT, 
IFRAME, OBJECT, EMBED, INCLUDE, and externally linked HREF should be stripped before the mail hits the display, or 
better stripped at the server before the client has a chance to touch it.  Using HTML for formatting is ok, but not 
using any form of scripting or code execution.  Links to external anything should not be allowed, if you need a picture 
in the mail, embed it or forget it.

Sandbox the mail client, then further sandbox the attachment handling until a level of trust or assurance can be 
reached - This might be overkill, I admit, but the attachment must be sandboxed, and I think that due to human errors 
and smart attackers, the mail client should be too, to provide the extra assurance that there will be no issues until 
some degree of trust can be established.

Integral AV scanning in mail client - No external software required to get AV Protection, it is provided by the mail 
client itself, maybe as a plugin from AV vendors to avoid sig maintenance issues.

No "double-click to read" feature - do not allow the native programs to be called directly from the mail program, do 
not allow viewing of the attachment right from the mail.  Attachments must be saved to fixed (but configurable?) 
directory structure, and the AV "watches" this directory for new files and scans them as they come in.

Integrated key exchange protocols for establishing secure sessions and support for the "major" encryption standards and 
hashing standards.


-----Original Message-----
From: Kenneth R. van Wyk [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 27, 2004 1:39 PM
To: [EMAIL PROTECTED]
Subject: [SC-L] Hypothetical design question


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