Jeff Tokayer wrote:
> I didn't realize that HTML was a security risk. I was under the
> impression that people avoided HTML because of the file size.
Some MUAs are vulnerable to embedded Javascript in HTML email.
Using a Mac *probably* decreases that risk to reasonable levels,
but I'm behind on reading the Vulnwatch mailing list. Note that
most legitimate PDML traffic will not include Javascript, but
some folks may quarantine (or reject) all HTML messages before
sorting on list/non-list. Also, even if an HTML message claims
to come from a known sender, it could be a forged header on a
worm sent by some other user's infected machine, so accepting
HTML mail from "people you know" (or lists to which you're
subscribed) doesn't make you any safer than accepting HTML
messages across the board.
AFAIK, pure HTML (no "active comment", no executables, no
Java, Javascript, ActiveX, etc.) does not provide a direct
avenue to compromise the recipient's system, but it does
still allow two types of indirect attacks that come immediately
to mind. The first is a simple privacy exposure: some spam
includes references to images to be loaded from a web server,
rather than included in the message itself, and the filname
of an image will be coded with the recipient's address to let
the spammer know that that message was opened and viewed in
an HTML-aware MUA -- that the address does actually reach a
human. And some people would rather not give out such clues
merely by opening (or for some mail programs, even seeing the
preview pane of) a message.
The second indirect attack is an HTML message that causes the
MUA (or a browser invoked by the MUA) to download active content
when viewed, so the message itself contains no Javascript code,
but causes a frame to be created in which a malicious web site
is viewed which contains Javacript.
Also note that if your mail client (MUA) and web browser are
separate programs, Javascript may be safer to execute in one
than in the other -- that is, they're not both using the same
"security sandbox". Feeling safe in one doesn't mean you
should assume the same about the other.
The file size is an _additional_ issue, which affects some
people more than others. Folks on dialup connections care
more. Folks with small disk quotas on their mail servers
care more. Folks who get womdigious numbers of messages
in the first place care more. Anyone in all three categories
is going to be pretty grumbly about mail taking up three times
as much space (and three times as much time to download).
Note that it's *possible* to send HTML email that is
a) not painful for humans to read without being rendered
by a browser or HTML-aware MUA, b) only a _tiny_ bit larger
than plaintext, and c) safe. The problems are that the
machine-generated HTML is universally _atrocious_ (both
pessimally formated for human reading and grossly
inefficient), and it's hard to write a mail filter to
automagically reject ugly HTML while retaining tidy,
efficient, safe HTML.
Email is fundamentally a plaintext medium, at least when
one is communicating with typed words. The fact that
we *can* frill it up with font- and colour-changes in
HTML mail doesn't mean that we *should* ... and most of
the HTML mail I see that isn't virus or spam doesn't even
*use* any HTML features anyhow; it just adds an extra
layer of cruft to no significant effect. I *have* run
into situations where it was actually _useful_ to send
an HTML message, and those occasions (all *three* of them)
stand out as exceptional enough to point out how silly
it is the rest of the time. (On two of those occasions
I sent hand-coded HTML that was effective communication
whether one read the source or a rendered version; on
the third occasion I found a different solution because
HTML wouldn't have been useful _enough_ to make it worth
dealing with for the person I was going to send it to.)
So it's kind of useful sometimes that many people have
the _ability_ to handle HTML email, but it's really
[expletive]ed up that so many users (and so many
programs) make it a _default_.
-- Glenn
