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)
MailNews Core
Security
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.
Reporter | ||
Updated•19 years ago
|
Whiteboard: [sg:investigate]
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.8b4?
Comment 1•19 years ago
|
||
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
Reporter | ||
Comment 2•19 years ago
|
||
> 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.
Assignee | ||
Comment 3•19 years ago
|
||
we're not removing this feature for 1.1
Flags: blocking1.8b4? → blocking1.8b4-
Updated•19 years ago
|
Comment 4•19 years ago
|
||
>> 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]
Comment 5•19 years ago
|
||
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!
Comment 6•19 years ago
|
||
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.
Updated•18 years ago
|
Flags: blocking-thunderbird2?
Assignee | ||
Comment 7•18 years ago
|
||
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.
Reporter | ||
Comment 8•18 years ago
|
||
That's basically the same as fixing this and adding some new UI, right?
Depends on: 357321
Assignee | ||
Comment 9•18 years ago
|
||
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
Reporter | ||
Updated•18 years ago
|
Whiteboard: [sg:want]
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•