Slashdot Mirror
Cookies are Security Hole in HTML Email
Richard Smith
just keeps uncovering security holes. Today it's the
Email Cookie Leak.
By reading mail, you unknowingly register your email address in someone's database, and accept their cookie. Next time you browse their site, or a site they have banner ads or other GIFs on, you are essentially broadcasting your email address while you surf. As Smith points out, just wait until
banner-ad companies
start taking advantage of this. I repeat the suggestion I made in October: browsers (and all clients that speak HTTP) should reject cookies not sent with the page.
Yes. I was also surprised when I realized that Java and JavaScript are automatically set to be useable in email as the default under Netscape mail... I turned that off promptly. Java execution in Netscape 4.7 seems to core an awful lot... which is really annoying.
In any case, I run everything through my junkbuster proxy, which makes me feel happy and secure... I recommend junkbuster to anyone and everyone who values their privacy and hates banner advertisements... especially the ones on slashdot. ;)
You'll eat it and you'll like it.
I have yet to find any problems with reading mail in pine or mail (mailx to some people). My favourite way is actually 'cat /var/spool/mail/`whoami` | less' - unless you have c^Hch^H^ha^H^ar^Hr you can't even make something bold there, let alone leave cookies :)
:)
0 m^[[40m^^[[12;2]^[[2J^[[1;1H^[[30m^[[40m ^[[12;3]^[[2J^[[1;1H^[[30m^[[40m^[[12;4]^[[2J^[[1; 1H^[[30m^[[40m^[[12;5]^[[2J^[[1;1H^[[30m ^[[40m^[[12;6]^[[2J^[[1;1H^[[30m^[[40m[[31m^[[5m^[ [20;20HMAILX IS NO SAFER THEN NETSCAPE MAIL!!^[[K^G" in a message and open it with mailx or cat, (on a linux console). (Replace ^[ with \x1B or \33 or however else you want to put ESCape there, and ^G with control-G. All other ^ are the property of their respective control characters. :))
Anyhow, the point is that reading mail with special effects is proving to be more costly then its worth to those of us who value our privacy, and the general security of our email.
Though - ANSI bombs are possible in mailx
include "^[[10;1999]^[[11;1999]^G^[[12;1]^[[2J^[[1;1H^[[3
Don't^H^H^H^H try this at home!
OFTC: By the community, for the community
First of all, note that there is nothing "groundbreaking" in this discovery. All this happens only if you are unlucky enough to have your email address in the hands of spammers, which is already as bad as it gets.
What can you do to prevent such abuse? Several things: Turn off HTML enabling for your email clients (you may or may not have a choice depending on the client). Restrict (or disallow) cookies in your web browser. Use something like Junk Buster.
Sreeram.
Connection: Keep-Alive
User-Agent: Mozilla/4.7 [en] (Win98; I)
Host: www.mybannerads.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Cookie: id=c643640a
Both the Email address and cookie value is included in the Outlook and Messenger GET requests. When the GET request is processed by the MyBannerAds server. It first extracts the customer id number from the cookie and looks it up its database of "anonymous" profiles of Web surfers. Once it has located the profile, it then extracts the Email address from the URL query string, turning a once "anonymous" profile into an "identified" profile.
So where does MyBannerAds get the Email addresses in first place to send out a message which includes the SYNC.GIF file? The answer is quite simple, they "rent" the Email addresses. Or more specifically, the rent space in junk Email messages that are already being sent out. The IMG tags typically take less than 100 bytes, so they can easily be embedded in messages that are part of any Email ad campaign that is using HTML Email messages. /privacy/wbfaq.htm
Another interesting discusion about HTML Email and cookies can be found @: http://www.tiac.net/users/smiths
> Is it possible that cookie info is stored in multiple places on modern browsers?
/. login (if you so wished), but no one else. I leave them enabled with confirmation required in Netscape, but I really get tired of having to click 'no' up to 7 times per page at some sites.
More reason to go to an open source browser.
Also, it would be nice to be able to hack your browser to support cookies only from authorized sites. That way you could enable them for your
> Anybody got a decent URL for cleaning out the cookie jar?
I haven't checked lately, but the GTK+ Application Repository used to have a cookie editor. It was submitted quite a while back, so you may have to hack it a bit to make it work with the more recent GTK libraries.
--
It's October 6th. Where's W2K? Over the horizon again, eh?
Sheesh, evil *and* a jerk. -- Jade
Netscape doesn't know my email address. java and javascript are disabled. And whenever anything blinks at me, I check the url and feed something to junkbuster to prevent it from happening again (sorry, hemos--yours blink, too :)
I'm glad we live in a world where Slashdot's YRO keeps us vigilant against the supposedly harmful effects of Internet society. I mean, if you think about it, there are many more Internet technologies that can, when used improperly, cause security violations on your system.
In this case, browsers simply need to be setup to function as individual components. The web browser should not have access to the same mechanisms as an e-mail client. HTML e-mail is different from loading a web page and should be treated as such. Cookies are not a part of HTML; they are a part of HTTP! The browsers shouldn't confuse the two. This isn't a problem with the implementations of cookies, this is a problem with the implementation of HTML e-mail and the web browser.
And the idea that loading cookies from only that page is ludicrous. The whole idea is to be able to give an entire site access to information so that you can do things on different pages with similar information without having to repeatedly ask for that information. There's nothing in the HTTP specification that makes this harmful. Someone simply didn't implement the specification properly so now clients can share cookie files, leading to a possible hidden exchange of data between them.
If you had actually read Richard Smith's article, you'll see that he addresses the issue of how the Ad company actually gets the email to the user:
1. Rent space on a mailing list where advertising is already sent out. Embed invisible GIFs in the email.
2. Get into the email servicing business or acquire an email servicing company.
Even then, though, what good would linking the cookie to their e-mail address do but to promote more spam?
From the company's point of view, it allows them to build better user profiles. e.g. several companies could get together and combine their databases (based on the email addresses that they now have) to build a profile of you the user.
won't appeal to reputable companies, who the advertising companies are targeting for money.
Think RealJukebox.
The point is, when they spam you, they add your email address in the message on their end. Sending an email to journey@jps.net? Your image callout would be "foo.gif?journey@jps.net". It won't matter if your browser thinks you're president@whitehouse.gov.
Added fun: if you receive mail at multiple addresses, they can relate all those email addresses to the same cookie set. Including emails you might receive through anonymizing systems, e.g. they'd know that "862139@anon.penet.fi"[1] was the same user as "journey@jps.net".
-Peter
[1] RIP
Old trick on how to automatically reject any cookies and avoid being bugged by pages requesting to put cookies:
1. cd ~/.netscape
2. rm cookies
3. touch cookies
4. chmod a-w cookies
The article discussed using a HTTP request for a gif to send your email address to the web server. Then the server would set a cookie on your system. With Outlook in the "Restricted' zone, cookies are disabled (unless you messed with the settings) and thus, a cookie would not be set(unless there's another bug somewhere I don't know about). When you later visit the site that spammed you, there is no cookie because outlook didn't save it.
I send all my spam to spamrecycle@chooseyourmail.com; which is inherently a huge mistake, but I hope they're doing something constructive with the info...
No there is a reason I use cat file | less rather then less file; here goes...
/var/spool/mail/`whoami`, then it shows up in in user userlisting 'w' what you are doing. If you use cat | less, you go to end of the file then go back it shows up as - ?, which affords more privacy.
when you use less
OFTC: By the community, for the community
Basicly, you just need to create a .cookies.allow file in your home directory containing the names of hosts (e.g. slashdot.org) for which cookies are ok. Cookies from anywhere else gets deleted each time the program is run. Makes it nice and easy to automate, since you don't have to go in and manually delete nasty cookies.
If you have any questions about setting it up, email me.
... is that email was designed with plaintext in view. If you want HTML, please go to a Website. Email has never been designed to be some lame, contorted "sub-Website" that runs on HTML!!!! The problem is that people have this bells-and-whistles mentality: "Oh, it will be so cool if my email has HTML formatting! Oh, it will be so cool if my email can contain inline images! Oh it will be so cool if my email can contain JavaScript animations! Oh it will be so cool if my email can run cool programs on my computer automagically! Oh it will be so NOT cool when my email can format my hard drive!"
Email with HTML is just disgusting. Especially the way it's currently done by the lame mailers that allow it: a plaintext version in the body of the email, plus an *attachment* with the HTML-ized version of the plaintext. Or worse with this annoying featurism trend, you have MS-TNEF attachments containing who knows what. I mean, WTF?!?! Talk about bloat. No wonder network bandwidth is always so congested. What's the f***ing problem with plaintext email anyways?!
Those people who really want this kind of sick featurism should seriously consider designing a NEW protocol, NOT EMAIL, that transports this kind of crap. And I think I know what that is, too. Automatically send a ZIP file containing HTML, GIFs, JavaScript, the whole ball of crap, and the User Agent on the other end automatically decompress the ZIP, run the browser to view it.
Alright, enough of this rant. But I just can't emphasize enough that featurism always leads to crappy implementations which in turn introduces all kinds of problems, like security holes, because the original protocol was never designed to support this kinds of "features".
mikre he sophia he tou Mikrosophou.
Browsers don't warn you about sending a request for an image. Read the article. Email containing HTML which requests an image can contain a URL with a code which uniquely identifies you. The server which processes that request is what picks up the ID which was sent you to, so they know you read that email.
But, if this worked, I could allow cookies to be initially accepted, which is far more convenient than clicking on half a dozen yes/no boxes every time I want to log in to a web site. Since I'd be able to see when cookies appear and where they originate from, I could also catch the troublemakers as they appear and just delete them on the spot.
Would it be possible to write a program to do this (Windoze or Linux)? I know that the cookie file, despite the warning that it shouldn't be edited, is a pretty simple text file with one line per cookie, and it's not too hard to sift out some obvious offenders after you're done browsing. I don't suppose it's that easy to modify cookies while you're actually browsing stuff though. Having notice of this info while browsing would be far more convenient though, and would save you the trouble of figuring out where a cookie came from that just has an IP address for its origin. (Not that that's terribly difficult, but its just a bit more of a bother.) If a web browser could be made with this feature built-in, it shouldn't be a problem at all to code and I would be eternally grateful (hint hint Mozilla!).
You know what to do with the HELLO. ...
Help create an open-source world
Check this scenario:
So now, any time (unless you clean your cookies or whatever) that you visit me.com you will send a cookie to my server and my server will know that you are you@you.com
See... I don't know why this is a big deal. It is actually pretty easy to implement.
HTML Email itself is a security risk. ALL browsers have security holes, and these holes have included things as serious as the ability to read arbitrary files, delete system files, and other nasties. I have seen the code for a page that will delete kernel32.dll on a Windows box running IE4.x or 5.x (given that the user has permissions on the file if you're running under NT) [code kiddies, don't ask for this, if you really want it, check out the bugtraq archives, Gregori Guninski is a genius], and Netscape has flaws that are just as bad [Netscape seems to have quite a bit more flaws than IE, I'm sad to say, which makes me an IE man]. In an effort to make browsers do more, there is a lot of the systems functionality integrated into the browsing experience, and with that exist ways to exploit those functionalities in nasty ways.
This cookies thing is just a drop in the bucket. If you still use HTML enabled email, you're asking for someone to drop you a bomb. If you really like a Microsoft mail client and you want to continue to be able to see HTML mail, make sure you put it in restricted zone! (it's in options) This won't totally protect you, unless you have "Internet Zone" security as high as it goes, because all it takes is for someone to drop an iframe in the email source (yes it's totally possible), and that iframe is a pointer to a page that whams you.
Slay a dragon... over lunch!
It's more of a privacy hole than a security hole (in the context that you used 'security').
People being able to acquire personal information and monitor your browsing habits without you knowing it doesn't increase the risk of them stealing your important files or sabotaging your network, it simply allows companies to violate Your Rights Online.
Seems to me that what's needed is for some enterprising individual with the right skillset (and more time than me) to write up a script (and then share it around widely) that will silently pass mail unless triggered by one of these Web Bug hooks (part of an established mail filter might do just fine).
On finding one, it should issue somewhere more than ten GETs (a hundred or more would be nice if you've got the bandwidth, we're talking about HTTP GETs here, not mailings) to that site, each time with a different cookie value, none of them the one that was sent.
If enough of us do this, the pool should be poisoned nicely. When they get wise to it, we'll have to advance to cronning the additional GETs.
We might also add it into a signature-file generator for any outgoing HTML mail, especially replies.
Maybe we can't help tying a ribbon around the tree with the pot of gold at the bottom of it, but we can tie a ribbon to every other tree as well.
In windows, there is a nice app called Cookie Pal that does this. To use it, you have to enable the alert message boxes for cookies in your web browser (netscape and IE both do this). Cookie Pal intercepts these dialog boxes and accepts or rejects for you base on settings you choose. Very nice. I would recomend it.
In a related story published in April on Wired, the use of redirect hyperlinks to track email by Deja is described.
Deja is basically tracking your creation of an email response to an article on their site.
According to the article:
"Deja News could also record -- and log -- the use of the link, the IP address of the sender, and the addressee's email [address]."
The ACLU has some rather pithy comments on Deja's practices in this area, including the possibility that Deja is in violation of the Electronics Communications Privacy Act by intercepting these transactions.
Not to worry though, Deja is a member of TrustE.
I guess this note will never meet the sight of most of the /.ers, but I had to bring this up because I found it an inherent flaw in Moderation in /.
/. Moderation Method (TM) ??
Do you remember the discussion about CEO of Novell and his apparent stolen credit card numbers ?? Well I had posted this story as reply number 37. Furthermore an AC had actually replied with the same link as used in this story.No moderator seems to have found it fit to give any extra points. But now, a whole new discussion with 90 replies seem to have started.
Hm.. A failure of
... "follow me" the wise man said, but he walked behind
How hard would it be to set up the email clents with a REJECT button, causing compliant mail servers to send a daemon error saying user does not exist or even "Your mail has been REJECTED by the recipient" ?
I think it would be a BITCHIN spam killer...
Cobratek
DONT TREAD ON ME MOÎΩN ÎABÃ
Even more reason to use Freedom from Zero-Knowledge at www.zeroknowledge.com. The
product is not out yet, it's in beta testing stage. It supports you having multiple anonymous
pseudonyms, works at the IP layer (I think) and filters all identifying information that it can find from your packets and ties them in with the pseudonym you select. Cookies go into separate cookie jars for each pseudonym. Quite cool.
I have a beta evaluation copy: haven't used
it too much, though it does slow down surfing a bit over a 56K modem connection.
Yumpee
Something I haven't seen anyone else mention (but then I browse at Score 2 :o) ), is that this does more than allows spammers to build up a profile of you and tie it to your email address. It also proves that the address is valid.
No longer will they have to rely on people following their "unsubscribe" instructions; merely reading the email will be enough to confirm that there is someone/something on the other end of the address they bought/harvested. They can then add the address to their list of confirmed active accounts - a pretty valuable thing to have, especially if you're in the business of selling addresses...
Tim
It's official. Most of you are morons.
I remember reading a .sig file a while ago that said:
/. reader. Credit where credit is due.)
;) (No flames please about the real legacy reasons that it's 7 bit, I know.)
"There is a special place in hell reserved for people who use html email."
(Sorry, I can't remember who it was, but I believe it was a
My sentiment exactly. I read everything in a shell with pine. Ain't no cookies going anywhere there... unless I missed something? Of course thats the personal mail. At work, I'm forced to use Outlook, but I am behind a firewall.
Email is text... and maybe attached files. It you want to imply bold, * * it.
No damn font changes, inline pics, none of that crap, that's why it's 7 bit.
The purpose of email is to convey information. Text does that just fine for me. If you send me html formatted messages, pine can't read them, I'm not going to go to the trouble to save and view them, and you have failed to convey your message... so sorry. Now I find out that it's a nice security benefit as well. I always knew I was on the right track.
It's sorta like web pages that are all filled up with Java and the like, I can't see them in lynx, so I can't get your content. Again, sorry, but you have lost a visitor.
Russ
War is Peace. Freedom is Slavery. Ignorance is Strength. - George Orwell or George Bush?
>>only a limited number of people have the ability to post original stories
I thought everyone had equal chance of getting their stories posted. Am I mistaken ??
... "follow me" the wise man said, but he walked behind
This thread is really about misuse of cookies, but the problem would be less severe if cookies were used less often in the first place. I wonder if they're being used as a universal panacea in areas where they're not really necessary.
What are the viable alternatives to cookies, at least for some applications? Are there any good web resources that discuss this kind of thing and offer means of avoiding cookie-based solutions?
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Oh post.. I first read it as "submit" ! :)
... "follow me" the wise man said, but he walked behind
If you break a story on a major security hole that most people don't know about on a weekend, most people are still not going to know about it.
I realize that this is not your intent, but, keep in mind that this is one of the oldest tricks in the book at newspapers like the New York Times. When there's an unfavorable story about the Clinton Administration, quite often the Times waits until Saturday, when no one is reading the paper, to break it.
You got 150 posts on this topic, but, I suggest you would have gotten a lot more on Monday. More importantly, lots more people would have assessed their exposure to the potential risks.
--
Dave Aiello
-- Dave Aiello
I think the major deal is that cookies should only be held within a specific user agent's environment. The fact that the e-mail client in question *shares* the same environment with the web browser is perhaps what should be corrected.
As far as I'm concerned, access to HTTP services from within an e-mail message should be a settable option. If you need access to images in an e-mail, attach them like normal file attachments and reference them with <a href="file://attachment1.gif">. If HTTP must be used, put each e-mail message in its own "sand box" so that state information (such as a cookie) is never shared between e-mail messages or between e-mail messages and web sites as browsed through a typical browser.