Closed Bug 303754 Opened 19 years ago Closed 18 years ago

Make false the default for "Allow remote images if the sender is in my [address book]"

Categories

(MailNews Core :: Security, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jruderman, Assigned: mscott)

References

(Blocks 1 open bug)

Details

(Keywords: privacy)

Thunderbird version 1.0+ (20050804). The "Allow remote images if the sender is in my [address book]" defeats the purpose of blocking remote images because it is so easy for spammers to work around. A spammer could set the "from" address to be: * The recipient's address (bug 263220). If the Thunderbird user has ever sent a message to themselves, their own address will be in their address book. * The recipient's address but @gmail.com instead of the recipient's domain. * Another email address scraped from the same web page, assuming that people whose addresses are listed together know each other. * The address of a popular newsletter, especially one that normally contains remote images. * The "feedback" address of a web site the spammer thinks the victim might have visited. Alternatively, the spammer could simply send the victim something the victim is likely to reply to, such as "Are you the Jesse Ruderman who went to Jefferson High School in Nebraska?". When the victim replies, the spammer would get into the victim's address book. (If the spammer didn't use a forged address, the spammer would also learn that the victim's address is active just by reading the reply.) The "Allow remote images if the sender is in my [address book]" feature should at least be turned off by default, and I think it should be removed too. As a replacement, there could be a whitelist of domains that remote images can come from.
Whiteboard: [sg:investigate]
Flags: blocking1.8b4?
Some of your objections only apply if the setting is set to allow remote images from all addresses in "Collected Addresses", rather than "Personal Address Book" (the default). Have you personally experienced problems with this? Gerv
> Some of your objections only apply if the setting is set to allow remote images > from all addresses in "Collected Addresses", rather than "Personal Address Book" > (the default). I don't see any addresses in "Collected Addresses". Everyone I've sent mail to is in my "Personal Address Book", and I'm pretty sure Thunderbird put them there. This is with a pretty new profile and a trunk build of Thunderbird. > Have you personally experienced problems with this? I don't know whether I've received spam that attempts to exploit this hole. I think that spam that appears to come from the recipient is fairly common, though. Spammers could easily discover this hole accidentally.
we're not removing this feature for 1.1
Flags: blocking1.8b4? → blocking1.8b4-
Keywords: privacy
OS: MacOS X → All
Hardware: Macintosh → All
>> only appl[ies] if the setting is set to allow remote images from all addresses >> in "Collected Addresses", rather than "Personal Address Book" (the default). > > I don't see any addresses in "Collected Addresses". Everyone I've sent mail > to is in my "Personal Address Book" Same here, probably has something to do with http://lxr.mozilla.org/mozilla/source/mailnews/mailnews.js#403 Effectively the current setting is "load remote content from anyone who claims to be anyone I've ever mailed in my life". That's a rather low bar considering that everyone has at some point CC'd themselves by reply-all'ing to a mail thread. An evil-doer setting From = To would have great success. Since the current bug--"remove the feature"--is effectively WONTFIX by the module owner (comment 3) I'm morphing this to change the default preference in the hopes that might fly. I've filed bug 322442 on the incorrect collection book default. That would greatly mitigate the risks, though an OE addressbook-havesting worm would still have reasonable success. Removing the confidential flag since it's not really an exploit.
Assignee: nobody → mscott
Group: security
Summary: Remove the "Allow remote images if the sender is in my [address book]" feature → Make false the default for "Allow remote images if the sender is in my [address book]"
Whiteboard: [sg:investigate] → [sg:want]
I think the problem is actually more one of "user education": the security aspects of having addresses autocollected into an addressbook that is then used for "lowering the fence" are visible to Joe User _nowhere_ in the UI!
I've now closed bug 322442 which turns out to be a dupe of a WONTFIXed bug -- the address books are combined on purpose. In that case the remote-blocking feature is easily defeated with the current default. One minor fix short of changing the default would be to exclude the user's address--all known identities--from whitelisting, whether or not they're in the address book (they almost certainly are). Ditto for giving the user's address a pass on junk mail scanning if they're using the addressbook to whitelist that. This wouldn't protect against all the vectors Jesse enumerates, but currently the user's own address is the one spammers are taking advantage of. The others would be more useful in a targeted attack -- the old "email from the boss" trick is still pretty effective for all sorts of social engineering attacks. As a completely separate issue we're seeing increased complaints about the use of in-line images. That will be addressed in a new bug Scott will file since it's not a privacy issue and the current nsIContentPolicy-based scheme can't address it. It may end up helping with this issue, though not in the near future.
Flags: blocking-thunderbird2?
Hey guys, I've posted an alternative possibility in Bug 357321 where by we always block remote images. From the remote image bar, a user can optionally choose to 'always allow remote content from this sender'. This results in a user editable address book card property being added for allowing remote content on a per card basis instead of automatically trusting anyone in the address book.
That's basically the same as fixing this and adding some new UI, right?
Depends on: 357321
This is now invalid given the new implementation that gets rid of htis feature all together in Bug 357321.
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Resolution: --- → INVALID
Whiteboard: [sg:want]
Product: Core → MailNews Core
QA Contact: security
You need to log in before you can comment on or make changes to this bug.