[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