Secure Coding mailing list archives
Re: Hypothetical design question
From: David Harmon <dmh () tiac net>
Date: Fri, 30 Jan 2004 22:12:13 +0000
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]
Current thread:
- Re: Hypothetical design question, (continued)
- Re: Hypothetical design question Louis Solomon [SteelBytes] (Feb 03)
- RE: Hypothetical design question Jason Wilcox (Feb 03)
- RE: Hypothetical design question Robert Shields (Jan 28)
- RE: Hypothetical design question Nick Lothian (Jan 28)
- RE: Hypothetical design question ljknews (Jan 28)
- RE: Hypothetical design question Nick Lothian (Jan 28)
- RE: Hypothetical design question Dave Paris (Jan 29)
- RE: Hypothetical design question ljknews (Jan 29)
- Re: Hypothetical design question David A. Wheeler (Jan 29)
- Re: Hypothetical design question Paco Hope (Jan 29)
- Re: Hypothetical design question David Harmon (Jan 30)
- RE: Hypothetical design question David Crocker (Jan 30)
- RE: Hypothetical design question Alun Jones (Feb 01)
- Re: Hypothetical design question Paco Hope (Jan 29)
- Re: Re: Hypothetical design question Kenneth R. van Wyk (Jan 29)
- Re: Re: Hypothetical design question der Mouse (Jan 29)
- RE: Re: Hypothetical design question Alun Jones (Jan 30)
- Re: Re: Hypothetical design question Jose Nazario (Jan 30)
- Re: Re: Hypothetical design question der Mouse (Jan 31)
- RE: Re: Hypothetical design question Ben Corneau (Jan 31)