Re: Hypothetical design question

[David Harmon <dmh () tiac net>]

I'm usually a lurker here, but I thought I'd toss in my .02c on this 
"secure MUA" thread.  Then I got on a roll... by 3AM last night, my 
missive seemed to have grown just a bit.;-)  [Mr. van Wyk, please feel 
free to trim this, I know I can be wordy.]  (BTW, I am very impressed 
with the quality of the discussions here in general.  Thanks, and keep 
it up, guys!)


First, it seems worthwhile to step outside the immediate frame of MUAs 
for a moment or so.  It seems to me that part of the problem here is 
that, having decided that "we" want to fix the mail-malware problem, we 
have a limited number of places to intervene and insert our solutions. 
(The use of "we" is not meant to claim the project or anything, I just 
needed a short pronoun.)


To try and list them:

        1) The Mail Transfer Agent
        2) The Mail User Agent
        3) Plug-ins and application programs (PIAPs) called by the MUA
        4) The Operating System.

I'll cover these out of order, mostly so I can get the non-starters out
of the way, then go on to the MUA, which is this thread's main topic.

The MTA:  I'm getting the impression that most of the writers here agree
that the MTA is a lousy place to put our solution.  Me too;  Doing it
there violates the end-to-end paradigm and places mail transmission in
general at risk from bugs, "friendly fire", compatibility probems, or
changes in the external situation.

The Operating System:
Obviously, the OS is a powerful and tempting venue for meddling.  It
might actually be practical to work here, *if* the OS provides the tools
and constraints needed to enforce automatic sandboxing.  Whoops, that
lets out Microsoft.... :-~  Then too, we'd be demanding total trust not
only from users, but from site and network administrators as well.  We'd
expose the whole machine both to our direct failures and to any OS bugs 
we might trigger with our meddling.  We also get to manage a chunk of 
configuration and coding for the system as a whole, which needs to 
interact with code we don't own, can't change, and can't get full 
internal specs on.  Oh yeah, and all this is supposed to be "secure". 
Riiight.


Plug-ins and Accessory Programs:
The PIAPs would at first seem to be a good place to handle this sort of
thing; after all, aren't these what the MUA calls to actually show the
message?  The problem is that not only are there many different PIAPs,
but their selection is user-configurable!  This makes it hard just
keeping track of them, let alone enforcing replacements.    I'd say it's 
probably better to consider any changes to PIAPs as a sub-project of a 
"secure MUA project", and simply include them in the discussion below.


What we *can* do with PIAPs, is to make sure that appropriately safe 
PIAPs are *available* for the relevant filetypes, and perhaps bundle 
them with our favorite or new MUA.  We especially need safe viewers for 
the Microsoft formats, and for HTML.  Of course, the user may himself 
replace one of the safe PIAPs with an untrusted program, but the only 
way to stop that leads straight back to the MUA...


The Mail User Agent:
I agree with the folks who've pointed out that the MUA is not a perfect 
place to put a solution to the mmware problem.  The issues mostly center 
around an application program trying to do things that don't fall within 
its narrowest purview (reading mail).  On the flip side, it's certainly 
the most *accessible* of the potential places to intervene.  It is 
(ideally) a standalone application, for which a replacement can be 
produced, marketed, and installed by individual users or site admins. 
Then too, the MUA is the proper "software owner" of unread and 
being-read mail, so it is perfectly reasonable for it to restrict or 
otherwise modify the user's protocol for accessing those messages. Of 
course, all of this means that the scope of the MUA application needs to 
expand, from "reading mail" to "reading mail *safely*".


Now, that one-word expansion certainly makes for a difficult problem,
but I doubt it's impossible.  The open software movement makes it much
more practical than it would be in many corporations..  As a number of
people have said here, in a commercial environment the developer is
likely to be treated as a flunky, expected to implement what other 
people or (gasp) committees have designed and/or decided on.  The tools

and code bases of Open Source allow a developer to break loose of this
cage.  He [/she/they] can produce a full-fledged application independ- 
ently, without being hamstrung by political or commercial idiocy.  Sure, 
you don't get the "support" of a funded business unit -- but haven't we 
just been saying that the business environment is part of the problem? 
 A solo developer can say "scr*w the market, I'm doing the Right 
Thing".  And if he does, just maybe he'll find that the "disassembled 
wisdom" of the commercial drones is flat-out wrong....


Ah, but, getting back to the main thread, what is "the Right Thing"
here?  In line with the above, I'd say it involves trashing a few bits
of conventional wisdom.  In particular, to build a secure MUA, we need
to add some limitations on the classic modular-design principles,
without utterly abandoning them.  The "obvious way" for a skilled
programmer to build an MUA depends heavily on those principles:

We build our program core to carry as little functionality as possible,
perhaps just the GUI and the MTA/spooler interface.  Instead of writing
things like Word plugins ourself, we supply interfaces for our MTA to
call various other programs for such services.  That way, we can easily
add features on the fly, by just calling other (existing or new) PIAPs.
We also try to have as few "rigid joints" as possible, allowing user
configuration of everything we can, including those interfaces.

Unfortunately, this is all wrong for security!  To make an MUA secure,
we don't want the user to be able to add arbitrary features at will.
Instead, we want to *restrict* the program's behavior, including 
policing much of the configuration, and restricting many of the 
features.  Likewise, we don't *want* our MUA to be executing

arbitrary programs.  We probably can't avoid having some sort of
hook for external viewers, just to handle new or obscure formats.  We 
can, however, make adding a new viewer a fairly picky process.  This 
would be carefully documented in the help, but we make sure it's not 
something a typical home user will do unless he actually needs to.
Of course, we must also provide secure viewers for all the common 
formats, so that most users *don't* need to!  Similarly, plugins

should run in a restricted and/or monitored environment, using whatever
means we can to defend against hostile or buggy code.

The other major issue to consider is the point that most of our users
are completely innocent of "appropriate suspicion".  Many are worse than
that ;-)  They also tend to quickly "lose interest in repeated stimuli."
That is, the first time they see an unfamiliar dialog box, they *might* 
read it carefully.  The tenth time they see it, they probably won't be 
checking details.  The hundredth time, they'll click through without 
even looking.  The response I propose to this, is that our programs need 
to be made *much* more assertive with the user. In particular, we must 
not be afraid to say "no" to a user, when they try to do something that 
is almost sure to be dangerous!


For starters, the MUA is *not* a general-purpose document viewer,
and it should not try to act like one.  For known or unknown file
formats alike, the MUA must not blindly ask the OS "hey, have you got
anything that can read .FOD files?"  Instead, it *only* checks if its
own viewers (some possibly added by the user) can handle them; if not,
it says as much to the user, offers to display the file as plain-text or 
hexidecimal, and perhaps suggests a visit to "our" support site. 
Individual viewers also need to have this same "higher assertiveness", 
and I've got quite a few ideas in this line.


Consider HTML mail and attachments.  These should get immediately
stripped down to text and well-behaved tags, with document info
collected in a sidebar.  Javascript never gets executed, nor does any 
ActiveX program (signed or unsigned).  By default they get displayed in 
glaring orange boxes, but the user can choose to have them silently 
hidden (or deleted from the message before storage?).  Come to think of 
it, that'll do for unknown or suspicious tags in general....


Images and other embeddings can be displayed if they refer to another
item in the same message.  Anything that leads off the local machine
gets displayed as some sinister-looking icon.  This is labeled
with the full URL of the reference, which is not only canonicalized, but
split, line-wrapped, and even scroll-barred as needed to make the
whole thing visible!  Left- or double-left-clicks on these reference
icons do nothing; right-clicking gets a popup menu with various options:

        Download this image
        Download all images from this site, for this session only
        Do a whois query on the site offering the image
        View the home page of the site (in our restricted viewer!)
        Google them
        Check for mentions on law-enforcement & spamfighter sites
        Read scary help pages about Web bugs and suchlike
        etc...

A similar strategy can be used against executable attachments.  Don't
even offer to execute them, show them as brain-sucking devil worms, and
automatically run them through antivirus checks, screaming bloody murder
on a hit.  (If the user didn't have an antivirus program, the MUA's
installer should suggest to go buy one!)

The general theme here is that we have multiple "lines of attack" in
pursuit of security.  We start with design and programming consider-
ations, and layer those with policy decisions which further inform the
design et al.  (e.g., constraining the plugin API.)  We also do what we
can in terms of sandboxing, virus scanning, etc.  Even the user inter- 
face has a vital role in guiding (scaring :-) ) the naive user away from 
pitfalls.  Other points to consider can be assembled from, say, the 
RISKS-Digest archives.  This adds up to a fair bit of work, much of it 
fairly picky, but surely doable.


Of course, then we get to start dealing with distribution, support, and
marketing.  Yet another good thing about open source is that programs
don't get pushed out to make some arbitrary deadline.  Even so, the 
first versions of things tend to be rather execrable.  In this 
particular case, those versions shouldn't be advertised much beyond the 
project's "interested parties" group.  That way, when we reach a *good* 
version, we can pull an Athena act, with the program apparently 
springing into existence full-grown, armed and armored.  (See, even 
marketing ties into security!  ;-) )


Even in a message of this length, I've barely sketched out some of the 
issues involved with an idea like this, but I hope my ideas are helpful 
to someone, and look forward to hearing your comments!


        Dave Harmon
        [EMAIL PROTECTED]