Thunderbird version 1.0+ (20050804) Steps to reproduce: 1. Telnet to an SMTP server and send yourself a simple HTML message containing foo <img src="file:///..." alt="bar" width="1" height="1"> baz 2. Using Thunderbird, retrieve the message. 3. Select Forward (inline) from the menu, or just Forward if you set your pref to forward inline by default. 4. Send the forward as HTML. 5. View the source of the resulting message. Result: It includes the contents of the local file that was referenced. Scope: * I tested with GIF and HTML files, so I imagine this hole allows an attacker to steal a file of any type as long as he knows its URL. * I tested with both http://localhost/* URLs and file:///* URLs. Both work, so this hole allows an attacker to steal intranet pages as well as local files. I haven't thought too much about how hard it would be for an attacker to convince someone to forward such a message to an address controlled by the attacker. I think it wouldn't be hard to come up with a scheme that worked at least 10% of the time, though.

This bug is similar to bug 88124.

One of those "forward this to ten friends or you will have bad luck" emails should get a pretty high success rate for this exploit. Combine it with a "and forward it to this address so we can see where it's got to" text and you'll have a good collection of people's files. Gerv

David: this is something we should really fix for beta, can you take a look at this ASAP?

This patch extends Jean-Francois fix for this same problem (but for replies) in Bug 88124 many years ago to also work on forwarded HTML messages. In my test, the image still loads in the compose window from my hard drive but when I actually send the forwarded message, we walk through the embedded objects, see that this was not something that came from the user so we fail to attach it to the outgoing message. This is consistent with the behavior seen when replying intead of forwarding.

Comment on attachment 192420 [details] [diff] [review] possible fix David, I'd like to experiment with this potential fix on the trunk. What do you think?

Comment on attachment 192420 [details] [diff] [review] possible fix seems worth a try

I've put this patch on the 1.8 branch too

I forgot to mark this closed since we checked in a fix. Although we may end up re-opening it if some of these regression bugs look serious enough.

Comment on attachment 192420 [details] [diff] [review] possible fix a=dveditz for drivers for aviary101 and moz17 branches

this fix looks like it's on the 1.7 branch and the 1.0x branch already. Am I missing something?

there were two calls to TagEmbeddedObjects on the trunk and one on the branches. I put the code as checked in (which is slightly different from this patch) onto the 1.08 and 1.7 branches.

the difference from this patch and what I checked in was to include the fix for the regression introduced by this change, i.e., bug 305557 - so that regression shouldn't happen on the branches.

David, when you landed this on 1.0.8 and 1.7.13, did you check in Bug 315625 as well as 305557? I think that was another regression that was caused by 305557. I'll try to look again tomorrow.

I didn't check in Bug 315625 but it looks like you did on 1/31 :-) the 1.5.0.1 branch contains the fix.

I meant 1.0.8 not 1.5.0.x. I'm pretty sure your the one that landed it on the 1.0.x / 1.7.13 branches :)

oy, too many branches. I definitely did not land in 1.08

David: I am confused - I took a quick look in bonsai for 1.0.8 and don't see this checkin. Can you clarify?

I did NOT land on the 1.08 branch - removing keyword. Is it too late to land in 1.08? Or did you land it, Scott?

David, why do you think this isn't fixed on the 1.0.x. branch? It sure looks like it was: http://lxr.mozilla.org/aviary101branch/source/mailnews/compose/src/nsMsgCompose.cpp#539 comment 11 comment 12 and comment 13 also support the fact that this was checked in. And because I was seeing the regression this bug caused on the 1.0.8 branch, so landed 315625 to fix that regression. That gives me even further confidence that this is in 1.0.8 :)

my happy mouse clicks accidentally marked this bug as verified. re-opening, re-closing to get back to the fixed state without verification.

duh, sorry, of course it is fixed in 1.08 - it's the fix for Bug 315625 that's not on the 1.08 branch.

or rather, I didn't check the fix for Bug 315625 on the 1.08 branch - you did :-)

Sorry to raise the red flag on this one, I was just trying to understand/make sure the appropriate checkins made it in. Sorry for the noise.

Verified with Windows Thunderbird - version 1.0.8 (20060317)