User: Password:
|
|
Subscribe / Log in / New account

Security

Did they read it?

May 26, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

Return receipts for email have been around for quite some time. They can be useful in some settings where a user is willing to verify that they've received an email without taking the time to compose a reply. However, the return receipt depends on the user's willingness to participate in the process. Often, for one reason or another, users do not wish to do that; these users can simply configure their email client to deny requests for return-mail receipts -- if, in fact, the user's email client supports that feature at all.

There are, however, those who aren't content to depend on voluntary responses. Rampell Software is peddling a subscription service for nosy correspondents who want to know whether or not their email has been read. Rampell is a company that pushes several spyware products for MacOS and Windows that are aimed at monitoring the use of other peoples' computers. The "DidTheyReadIt" service is aimed at people who are determined to know whether or not their mail has been read, and who are willing to pay for the privilege.

This, of course, has some not-so-pleasant implications for personal privacy. While the company assures its potential customers that it respects their privacy, nothing is said about the privacy of the recipient who may not wish to divulge whether or not they've read a particular email or where they've read it from. On the company's About Us page, they identify what kinds of people might want to find out whether an email has been read -- including some that make DidTheyReadIt sound like a must-have for potential stalkers:

Users of online dating services such as match.com who want to know if their potential dates are reading their messages...or ignoring them.

It isn't particularly cheap to violate others' privacy either, at least not when using DoTheyReadIt on a regular basis. A quarterly subscription for the service, with the ability to track 500 messages per month, is $24.99.

To use the service, the user has to send email through DidTheyReadIt's servers by tacking ".didtheyreadit.com" onto the recipient's email address. DidTheyReadIt's server then tags the email with a "web bug" and sends it on its way to the intended recipient. For the uninitiated, web bugs are a well-known spammer trick to verify working email addresses. The spammer includes a bit of HTML in the email that will request an unique image name (usually a small image that is invisible to the reader) from a remote server that tracks the hits. The image name and email address are paired so that the spammer can identify working email addresses with users gullible enough to open the spammer's email. When the image is requested from didtheyreadit.com, a hit is logged and the sender can then view the information on the DidTheyReadIt website and/or be notified via email.

DidTheyReadIt takes the web bug idea further than the spammers do, however. It responds to the request for the web bug image by sending a slow stream of data back to the mail client; that stream will continue until the receiving system resets the connection. The amount of time the connection was allowed to run will be roughly equivalent to how long the message was on the reader's screen, giving a sense of how seriously the message was read.

When the service works, the amount of information provided to the sender is quite intrusive. Not content to simply verify that a user opened an email, [DidTheyReadIt report] DidTheyReadIt reports the number of times an email is read, how long the recipient spent reading it, when it was opened, the location of the reader, the IP address of the recipient at the time the message is opened and their ISP. Not only is the recipient (including anybody the message may be forwarded to) being monitored in their reading habits, they are also being physically tracked when the service is able to pair up a geographic location with an IP address. While it's not possible for the service to report a street address, it can narrow down the location to a city. It's easy to imagine scenarios where this would be particularly undesirable.

Users who are even moderately knowledgeable about the way that the Web works will have no problem blocking DidTheyReadIt from divining whether or not they have opened an email sent through this service. Rampell's claims of success "the vast majority of the time, upwards of 98% in extensive testing" are a bit suspect. In fact, many users are already protected by sane defaults in their mail clients that prohibit the display of remote graphics in HTML email by default.

This writer had to deliberately disable the defaults in the Yahoo! and SpamCop (which uses Horde) webmail clients to allow DidTheyReadIt to track test emails. The tracking did not work with Thunderbird or Opera's mail client. It goes without saying that users of mutt and Pine will easily slip under the radar.

Furthermore, once word gets around about this service, many users may simply opt to filter out email that passes through the DidTheyReadIt servers altogether. Some folks might also decide to play havoc with this service by writing scripts to call random images from DidTheyReadIt's servers to generate false positives and render the service useless. Ed Felten predicts that DidTheyReadIt will not succeed in the long run:

Products like this sow the seeds of their own destruction, by triggering the adoption of technical measures that defeat them, and the creation of social norms that make their use unacceptable.

One would hope that the use of such a service would be considered "unacceptable" by most people already. Whether or not that is true, however, the use of free software for crucial tasks like email gives users the upper hand against this sort of service. There is, after all, nothing that forces us to tolerate a mail system which supports this kind of monitoring. If only all of our email problems were so easy to solve.

Comments (7 posted)

New vulnerabilities

firebird: Locally exploitable stack overflow

Package(s):firebird CVE #(s):
Created:May 24, 2004 Updated:May 26, 2004
Description: A buffer overflow exists in three Firebird database binaries (gds_inet_server, gds_lock_mgr, and gds_drop) that is exploitable by setting a large value to the INTERBASE environment variable. An attacker could control program execution, allowing privilege escalation to the UID of Firebird, full access to Firebird databases, and trojaning the Firebird binaries. An attacker could use this to compromise other user or root accounts. See also this bug report.
Alerts:
Gentoo 200405-18 Firebird 2004-05-23

Comments (none posted)

kernel: exploitable bug in the cpufreq code

Package(s):kernel CVE #(s):CAN-2004-0228
Created:May 24, 2004 Updated:May 26, 2004
Description: Brad Spender discovered an exploitable bug in the cpufreq code in the Linux 2.6 kernel.
Alerts:
Mandrake MDKSA-2004:050 kernel 2004-05-21

Comments (none posted)

SquirrelMail cross site scripting vulnerabilities

Package(s):squirrelmail CVE #(s):CAN-2004-0519 CAN-2004-0520 CAN-2004-0521
Created:May 21, 2004 Updated:October 4, 2004
Description: Several unspecified cross-site scripting (XSS) vulnerabilities and a well hidden SQL injection vulnerability were found in SquirrelMail versions 1.4.2 and lower. An XSS attack allows an attacker to insert malicious code into a web-based application. SquirrelMail does not check for code when parsing variables received via the URL query string.
Alerts:
Fedora-Legacy FLSA:1733 squirrelmail 2004-10-02
Conectiva CLA-2004:858 squirrelmail 2004-08-12
Whitebox WBSA-2004:240-01 SquirrelMail 2004-06-21
Gentoo 200406-08 squirrelmail 2004-06-15
Red Hat RHSA-2004:240-01 SquirrelMail 2004-06-14
Fedora FEDORA-2004-160 squirrelmail 2004-06-09
Fedora FEDORA-2004-159 squirrelmail 2004-06-09
Gentoo 200405-16:02 squirrelmail 2004-05-25
Gentoo 200405-16 squirrelmail 2004-05-21

Comments (none posted)

xpcd: buffer overflow

Package(s):xpcd CVE #(s):CAN-2004-0402
Created:May 24, 2004 Updated:June 1, 2004
Description: Jaguar discovered a vulnerability in one component of xpcd, a PhotoCD viewer. xpcd-svga, part of xpcd which uses svgalib to display graphics on the console, would copy user-supplied data of arbitrary length into a fixed-size buffer in the pcd_open function.
Alerts:
Mandrake MDKSA-2004:053 xpcd 2004-06-01
Debian DSA-508-1 xpcd 2004-05-22

Comments (none posted)

Page editor: Jonathan Corbet
Next page: Kernel development>>


Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds