Keith writes:
My suggestion is that we define a "safe" subset for each of the
content-types, that would not permit undesirable side effects.
If a body part is labeled "content-type: text-plus/postscript",
it should be within the safe subset. If it's "binary", no such
restrictions apply.
This is superficially reasonable but completely unattainable in practice.
Examples:
(1) PostScript. The biggie in PostScript is file operators. Fine. How do you
find them in a given input source? I can write a PostScript program that
implements a decryption algorithm using a key that's itself encrypted and
stored deep within the PostScript environment (hence it is totally
inaccessible to the mail system). Then I can direct the PostScript
interpreter to use this program as its own input filter and read
the rest of my messages as an encrypted program, which it then executes.
Now, how are you possibly going to know if this encrypted program, which
you don't have the key to decode, contains a Trojan Horse or not?
You may say that this scenario is extremely unlikely. Wrong! This is
more or less how type 1 fonts are actually distributed. The idea is let
people run these programs that draw characters without providing any way
to know how they work internally. This feature of PostScript is heavily
used in practice and many applications will croak without it.
PostScript also supports direct downloading of machine code to specific
interpreters. And far from being an unfrequently used feature,
Macinstosh applications that generate PostScript make very heavy use of
this ability. Are you going to scan the machine code for bugs too?
(2) PostScript, along with many other languages, also suffers from the problem
that users can exploit bugs in a given implementation (things like a
failure to check an array for overflow. How are you possibly going to
find these things? I tell you how -- you aren't. Locating them is
equivalent to the halting problem. The only, repeat ONLY, way to make sure
a program is completely safe is to run it in an environment that
has been proven to contain no exploitable holes. But this is a requirement
of recipient software; it has exactly nothing to do with the program you
run.
(3) To reemphasize the "one man's meat is another man's poison" theme,
consider plain old escape sequences again. I know of a perfectly reasonable
escape sequence that will crash (!) a VT100 terminal because of a
firmware bug. The terminal bell begins to sound and will not stop until
you power cycle the terminal. Now, this is not exactly a Trojan horse, but
you should see the results of broadcasting it to all the terminals in a
large computer center. It can takes hours to get the place back to normal.
(And yes, I speak from experience.)
The problem goes deeper than this. A sequence that does something
reasonable on one terminal may do something nasty on another. Since you
have no idea what people have and are going to read stuff on, you have
no way of checking this at the time the message is sent or while it is
in transit.
Of course, the responsibility to enforce the restrictions is
necessarily with the recipient's mail reader. Many text-only mail
readers filter out non-printable characters to protect the reader from
malice; this is only an extension of that practice. For example, a
text-plus/postscript body part might be prefixed with a header that
redefines all of the file i/o and "run program" routines to do
something harmless. A binary/postscript body part wouldn't get the
special treatment, but the mail reader would ask the before running
the program.
But this is crazy! Why would I treat a text-plus/postscript body part any
differently than I treat a binary/postscript body part? I am then trusting
the person who sent the mail to have categorized it correctly. Why on
earth would I have such trust?
I realize it might take some careful analysis to identify the "safe"
subsets of postscript, tex, troff, or whatever. But I don't think we
can ignore the issue.
You'd better be prepared to ignore these issues because they are completely
intractable. Any proposal you come up with I will happily shoot full
of holes.
Once again, let me repeat my earlier posting. If you want to be able to trust
what you receive, you must be prepared to authenticate the sender. Then the
trust issue boils down to whether or not you trust the person you KNOW
sent the message. This is truly the bottom line.
You can employ the superficially reasonable stopgap of trusting your PostScript
interpreter (or whatever) to impose the security restrictions you then specify
based on who you KNOW sent the message. This then amounts to trusting the
people who wrote the interpreter that they didn't leave any holes or bugs of
their own. The reality, however, is that people don't bother to check stuff
like this when they buy a PostScript interpreter and they probably never will.
Thus, the best you can hope for is to know who did something to you when it
does happen.
Ned