January 2000
		Search
		Navigate
		Home   Next Story Mail this Article Printer-Friendly Version
		Navigate
		Subscribe, It's Free Topical Index Backissues SunWHERE Letters to the Editor Events Calendar TechDispatch Newsletters
		Technical FAQs
		Solaris Security Secure Programming Performance Q&A SE Toolkit
		SunWorld Partners
		Software Store Career Central Sun Microsystems ITcareers
		About SunWorld
		SunWorld FAQ Advertising Info SunWorld Editors Masthead Editorial Calendar Writers Guidelines Privacy Policy Link To Us! Copyright
		Advertisement

Read an email, lose your privacy

Email can be spammer's weapon in more ways than one

Summary
Assorted cyberprivacy organizations are asking regulators to fix a privacy leak in Web browser software. Rich Morin tells us why leaks are only a small part of the problem. (1,000 words)

	SILICON CARNY
	By Rich Morin

he headline shouted "E-Mail May Be Peril to Privacy" from the business section's front page in the San Francisco Chronicle. Reading the December 4 article by Associated Press writer Kalpana Srinivasan, I was happy to see the issue getting some attention but hardly surprised to hear about yet another privacy threat. David Brin, the author of The Transparent Society, writes that a lack of privacy is inevitable. Although I don't agree with everything he says, the odds look pretty good that Brin might be right about this.

And while I hope Scott McNealy is using hyperbole when he says, "You have zero privacy now. Get over it" (the PC Week "Quote of the Week," Feb. 1, 1999), it's not at all clear that he is. Every time I'm asked to have my signature digitized for posterity during a credit card purchase (which I refuse, as a matter of principle), I am reminded of just how invasive our society has become.

Hiding HTML links in email
Enough generalized paranoia, however. Let's look at some specific threats.

Most Web browsers hide the HTML portion of a link, showing only a highlighted word or two. Many email clients, particularly those embedded in Web browsers, perform this service as well.

It is a useful feature, in most cases. After all, HTML code is both bulky and mysterious; most email users have neither the expertise, time, nor motivation to analyze every incoming bit of HTML. Unfortunately, however, it can leave an unwary user open to privacy attacks.

Let's say I get a piece of spam from a porn site, containing includes the following bit of HTML:

   <A HREF="http://www.smuttystuff.com">www.smuttystuff.com</A>

No problem so far: www.smuttystuff.com is just a Website, so I should be pretty anonymous visiting it. All the site will get from my visit, in general, is an IP number or perhaps a domain name. The site can't use either of those to send me more spam or identify me as a visitor.

Unfortunately, URLs can contain other items, including parameters that can be transmitted back to the site:

   <A HREF="http://[email protected]">www.smuttystuff.com</A>

If I take the bait and visit the site, my email address, [email protected], can be put on a hot list. Of course, the site managers had already obtained my address from an existing list, but they didn't know I would take the offered bait. Now they do.

It gets worse. If I am using such a Web browser to handle my email, even opening the email message may be enough to initiate a serious loss of privacy. Many Web browsers are capable of enhancing email messages with all sorts of (possibly invisible) images, retrieving them when a message is opened from any specified URL. The spammer is free to include an IMG tag that includes my email address in a parameter, as follows:

   <IMG SRC="javascript:void(0);">

Wanna cookie?
The spammer now knows that I opened his message, but even that's not the worst part. The Website can also return a cookie to my browser containing my (possibly disguised) email address. This means that any future visit I make to his site (or other, cooperating sites) can be recorded and indexed to my email address.

In short, my privacy will have been severely compromised by my email software, without my knowledge or permission. For more information on this specific kind of attack, see the Electronic Frontier Foundation's press release or the technical report by security expert Richard M. Smith (in Resources, below).

Variations
These sorts of attacks can take many forms. For instance, it is quite possible to eliminate the need for a parameter altogether. Let's say the image request looks like this:

   <IMG SRC="javascript:void(0);">

That seems pretty innocent, from a privacy perspective, but it might not be. In one possible scenario, the spammer could generate a unique URL for each outgoing email message, joining random names (susie, tammy, ...) with random letters (q, r, and so on). As each piece of email is sent, the spammer saves the outgoing email address in a database, keyed by the unique portion (susie_q) of the URL.

When the image request is received, a hidden CGI script (http://www.smuttystuff.com/blonds) can record the request in the database, send me an identifying cookie, and so on. In short, any image request could be tagged.

Finally, if I am foolish enough to click on an unknown URL, the spammer doesn't need parameters or even "hidden" HTML:

   http://www.smuttystuff.com/blonds/susie_q.html

The same logic applies: because the spammer knows whom he told about susie_q, he knows who is asking to see the Web page. Welcome to spamland, sucker.

Conclusions
One moral of this story, like that of Ken Thompson's classic paper, "Reflections on Trusting Trust" (see Resources), is that Trojan horses can come in many guises, and one should not trust a stranger's offerings, even if they contain no visible threats.

Another moral is that convenient "features," made possible by aggregating pieces of software (in this case, email and Web clients), can lead to unexpected security holes. Microsoft is the most obvious perpetrator here, but Netscape and others have contributed to the situation.

In an environment where random miscreants can send email to unsuspecting victims, keeping a few barriers in place seems only prudent. The spate of emailed "macro viruses" provides a clear example of the reasons.

Putting macros -- interpretable code -- into word processors and other programs is clearly a powerful and useful idea. Having email software start up a copy of the word processor, so you can read formatted mail, is also quite convenient. Unfortunately, the combination means that ill-wishers can run macros on a victim's machine merely by sending email.

I don't have any global solutions to offer, but I can offer some advice: Don't use Web browsers or highly integrated systems, such as Microsoft Outlook, as email clients; they're far too accommodating to spammers.

If you must use unsafe email software, try to use it in a conservative manner. Turn off any automated features, such as automated program invocation, that might allow others to take over your machine. Until the vendors add some real security, the risks far outweigh any possible convenience.

Editor's note: The domain name Smuttystuff.com was not registered at the time this article was published. Any similarity to an existing domain name or Website is purely coincidental.

About the author Rich Morin operates Canta Forda Computer Laboratory, a computer consulting firm specializing in open source software. He lives in San Bruno, Calif., on the San Francisco peninsula.

	Resources and Related Links
	The Transparent Society, David Brin (Perseus Books, 1999): http://www.perseusbooks.com Prepublication version of Chapter 1: http://crit.org/http://crit.org/openness/sourcedocs/BrinCh1.html "The Cookie Leak Security Hole in HTML Email Messages," Richard M. Smith: http://www.tiac.net/users/smiths/privacy/cookleak.htm Electronic Frontier Foundation press release: http://www.eff.org/pub/Privacy/Profiling/19991202_joint_profiling_pressrel.html "Reflections on Trusting Trust," Ken Thompson (Communication of the ACM, August 1984): http://www.acm.org/classics/sep95 Additional SunWorld resources Previous Silicon Carny columns in SunWorld: http://www.sunworld.com/common/swol-backissues-columns.html#silicon The SunWorld Topical Index -- a comprehensive listing of all SunWorld articles by subject: http://www.sunworld.com/common/swol-siteindex.html Visit sunWHERE -- launchpad to hundreds of online resources for Sun users: http://www.sunworld.com/sunwhere.html Explore back issues of SunWorld: http://www.sunworld.com/common/swol-backissues.html IDG.net, your one-stop IT resource: http://www.idg.net

	Tell Us What You Thought of This Story
	-Very worth reading -Worth reading -Not worth reading -Too long -Just right -Too short -Too technical -Just right -Not technical enough Comments:   Name:   Email:   Company Name:

If you have technical problems with this magazine, contact [email protected]