Re: Hypothetical design question

["David A. Wheeler" <dwheeler () ida org>]

Never, ever, execute ANY code sent by email.

The presumption of some of these statements is that it's a good idea to
execute arbitrary code sent by email from people you don't know.
Yes, sometimes the email address says it's from people you know, but
that's never true.  Email is trivially spoofed or caused by controlling 
someone's

system (cf: the latest email/Outlook worm).

I'm sorry, but I think that notion is rubbish.
The solution is to never run email clients that grant such unwarranted 
trust.

It's true that one popular email client has this security flaw.
But the fact that the vendor is unwilling to acknowledge the security 
flaw is

irrelevant; a flaw is a flaw.  Almost no other email clients have this flaw.
If the problem is unique to Outlook, it should be called an "Outlook worm";
there's no point in claiming it generalizes to other systems if it doesn't.

If an attachment has one of the few "trusted" data types
I can mediate with trusted programs (PDF for example) I'll open it, using
a program specifically designed to sandbox that specific data type.
Because the program is special-purpose, and is _designed_ to
prevent general-purpose access, all sorts of checks can be
made to prevent attack.  If the attachment is a general-purpose executable,
I don't execute it, and I don't run email clients that allow it.  I 
won't save

it and try to execute it, either.  I just don't execute it, and make sure
my client won't do it by double-clicking.  Period.

Executing general-purpose executables sent via email at all
is the mistake.  Everything else after that is a futile attempt to 
bottle a tornado.


If someone has a wonderful executable they need me to run, they can place
it on a web site.  I now know that at least they can control that web site,
which is a much better proof of identity than a maybe-spoofed email.
I can talk to them to ensure that the executable is okay, I can wait and
execute it later, the executable can be removed from the site if it's
malicious, and so on.  Yes, that's still vulnerable, and sandboxing
the executable as well is a good idea, but that lowers risks far
better than thinking that emailed executables was ever a good idea.

Clearly, sandboxing is a way to limit access, and COULD be used to
make this action more secure.  But the history of sandboxing is not
very encouraging.  Rather than take a potentially lethal virus into my
home and "protect" it with a dime-store container, it's much better to
use other mechanisms, and then add sandboxing if warranted.

Don't allow general-purpose emailed executables, period.  It's 2004, and I
_still_ have _zero_ problems because I refuse to run executables sent
by email.  And I suspect most people, if they switched email
clients, would discover the same thing.  And really, is this
functionality so important that you need to have more vulnerabilities?
My time is too valuable to me to mess with trivially-countered
problems like this.  While others worry about the nasty
executables sent to them, and how to clean up afterwards, I'm getting 
work done.


--- David A. Wheeler