[kde-linux] kmail - turn off html?
Duncan
1i5t5.duncan at cox.net
Thu Dec 31 23:52:49 UTC 2009
J J Murphy posted on Fri, 01 Jan 2010 04:43:33 +1100 as excerpted:
> On Fri, 1 Jan 2010 02:58:21 am [Anne Wilson] wrote:
>> The reason that html mail is so disliked by 'geeks' is that
>> there have been instances where malware has been successfully
>> and invisibly embedded.
> I've heard this before - but two (genuine) questions:
> 1. (a) Are there real examples of this -
> (b) how could they infect a *nix OS?
1a) (1) Yes. Most if not all of the mail client attack vectors, all
those vulns in Outlook, Outlook Express, Netscape's mail client, etc,
were tied to automatic parsing of the HTML content. Had the clients been
plain text only, not parsing the HTML, the attacks could not have worked
as they did. The worst that could have happened were they plain-text-
only would have been the classic "social engineering" attack, attempting
to convince the users that the attached file is legit and should be run,
thus invoking the malware that way. That's bad enough, but having them
automatically parse and actively act on the instructions therein, for
whatever comes to them, was a recipe for disaster to begin with, that
really, by that time, should have been foreseen as such, as we were
already long past the utopia of the original malware free net, when these
things first became popular. (BTW, as far as I know, while the MS
clients get a bad name here, they were simply competitively copying
Netscape's features when they introduced HTML mail. Netscape had its own
vulns in the area as well. I call a pox on both houses for their
irresponsibility in this regard, but by far it was NOT all MS' doing!)
1a) (2) Even if directly active infection vector malware is discounted,
read up if you wish on the spyware technology called variously web bugs
or web beacons (the latter is less ambiguous, as there's an entirely
different technology called web bugs as well). As originally mass-
exploited, this works on the image tags of an HTML page/message, but it
can be done with CSS, javascript, anything external to the web page (or
multi-part message) itself, that's dynamically fetched at viewing time.
In simple form, they use a link such as:
example.com/images/bug.gif?murphyjj-at-bigpond
to fetch the image, which doesn't even have to exist, but often does as a
single pixel transparent image. When your browser/mailer parses the page
and fetches that image, BOOM, the spammer just got confirmation that your
particular email address is valid! Now he can (and likely will) put your
address on his "confirmed" list, and sell it to other spammers as such.
Spammers pay good money for such "confirmed working" addresses!
Of course, it's normally not quite that easy to spot. Normally, they'll
either encrypt the query bit (after the ? in the link), and decrypt it
on-the-fly at the webserver, or they'll simply create a lookup table when
they're creating the mail, and reference that table to find the address
to confirm when they get a hit. Also, as I said, it's not always
images. So for example it might be a link in the page headers to a CSS
file like this:
example.com/css/mycss.css?21435834
That's obviously far harder to detect, especially since such queries are
used for various legitimate purposes as well.
The antidote to such web beaconing techniques is the two-stage HTML
permissions kmail uses. Don't enable it at all by default, but if it is
enabled (at the first level), only parse the html as it exists on-page,
don't let it out to fetch anything else. Only if you're sure you're OK
with whatever web beacons might be included, should you click that second-
stage permission, saying OK, go fetch whatever the web page says to
fetch, thus (normally) bringing in the various images in the newsletter,
or whatever, but ALSO exposing one to any web beacons, thereby confirming
to <whoever> that someone at that specific email address opened the mail
in HTML format.
1b) The point isn't whether I specifically might be infectable or not.
While I don't make the mistake of believing I'm invincible (rather the
opposite, the assumption is that if someone had enough motivation, they
could crack me), I do hope that the level of precautions I take keep me
out of the worst of it, and that my profile is low enough that they don't
have reason to target me specifically, and simply move on to easier
targets.
Bad analogy time! =:^) Because of my age and where I traveled as a kid,
I'm one of the folks that got a smallpox vaccine, after it was considered
basically eradicated (tho it hadn't been officially eradicated yet). But
suppose some guy was waving this vial of what he called smallpox around.
Just because I expect and hope that my earlier vaccine would protect me
to some degree, does *NOT* mean I'd be sitting there, simply watching him
do it, as entertainment or something! Rather, I'd be even MORE likely to
be trying to get it out of his hand, hoping that vaccine would be some
protection if worse came to worse, while warning everyone else to GET
AWAY NOW!!
Likewise, it's not whether I'm infectable or not, but rather, whether the
behavior observed is something I consider a danger to a reasonably sized
part of the community or not. HTML mail can be dangerous. That's a
fact. Sliming your hand with snot and offering to shake hands is
dangerous. That's a fact. Both should be discouraged. That's a personal
opinion, but solidly supported by fact. The more we can discourage such
behavior, the better off we as a community are.
> 2. Is this a valid danger compared to others - such as spoof/malicious
> sites, illegal remote log-ins and other techniques (some conceivably
> even beyond the user's control)? (As I stated in my original posting,
> I'm not objecting to lists insisting on no HTML, I'm commenting on the
> general attitude that this email illustrates to HTML - which is the
> defacto standard of the commercial world; like it or not.)
2) The problem isn't HTML per se. I doubt if anyone could sanely argue
against the web at this point and be taken seriously. Rather, it's to
HTML for use in mail and news (that is, Internet messages, in the RFC
sense). It wasn't designed for that and can be quite dangerous when
allowed to be used for that.
As for being a commercial standard, yeah, there's a commercial reason for
the web beacons typically embedded in the "newsletters" various
commercial sites offer, certainly. And there's a reason a business
contact might wish to confirm that I got and read an email. There are
actually mail protocols that allow such confirmations directly, and most
popular email clients support them. But you know what, they tend to be
turned off by default for a large enough portion of the emailing populace
that they aren't a reliable indicator at all. Ever considered why that
might be? People like their privacy, yes, even in business, or when
"people" /means/ a business. Now there's web bugs and the like, to try
to get around that. Should they be allowed by default any more than the
previous automatic read-mail confirmation? That's not even /considering/
the more active malware. Just because a rather large segment of the
commercial world has an interest in knowing whether I read their email,
and whatever else I might do on my computer, if they employ more active
spyware; just because a very active but shadowy segment of that
commercial world are spammers and malware purveyors of a more direct
sort, doesn't mean that I want them violating my privacy!
And that would certainly apply to most businesses that would communicate
by email as well! Think of the sensitive information that could be
gleaned from just web beacon technology! If you submit a bid either via
email, or send an email regarding it, and you see only a single hit, you
can gather it didn't go far. If you continue getting hits, possibly from
different IPs, particularly if you get hits tracing to the area of the
branch office of the person you sent the bid to, then from corporate HQ,
you have a pretty good idea your bid was taken seriously, as the mail
gets forwarded around inside the company. (Well, either that, or it's a
pitifully hilarious joke!)
Why any company would be willing to by policy allow such potentially
sensitive information out... is beyond me. From what I can figure, it's
simply down to politicos rather than tech heads running the typical
company... of course IMO the big reason MS got so big in the first
place...
Just because MS Office is a de facto standard... doesn't mean it's the
right one, either... Yes, I'll allow that both it and html mail might be
a business necessity in some cases, but that doesn't mean use of either
one should be encouraged where it's *NOT* such a necessity. Rather more
the opposite!
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde-linux
mailing list