Forward inline attaches externally referenced local files and intranet files

RESOLVED FIXED

Status

defect
RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: jruderman, Assigned: Bienvenu)

Tracking

({fixed1.7.13, fixed1.8})

Dependency tree / graph
Bug Flags:
blocking1.7.13 +
blocking-aviary1.0.8 +
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix] requires fix for regression 305557)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
This bug is similar to bug 88124.
Flags: blocking1.8b4?
Flags: blocking-aviary1.0.7?
Whiteboard: [sg:fix]
(Reporter)

Comment 2

14 years ago
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?
Assignee: nobody → bienvenu
Flags: blocking1.8b4? → blocking1.8b4+

Comment 5

14 years ago
Posted patch possible fixSplinter Review
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 6

14 years ago
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?
Attachment #192420 - Flags: superreview?(bienvenu)
(Assignee)

Comment 7

14 years ago
Comment on attachment 192420 [details] [diff] [review]
possible fix

seems worth a try
Attachment #192420 - Flags: superreview?(bienvenu) → superreview+

Updated

14 years ago
Attachment #192420 - Flags: approval1.8b4+

Comment 8

14 years ago
I've put this patch on the 1.8 branch too
Keywords: fixed1.8

Updated

14 years ago
Depends on: 305557

Comment 9

14 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Reporter)

Updated

14 years ago
OS: MacOS X → All
Hardware: Macintosh → All
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8+
Whiteboard: [sg:fix] → [sg:fix] requires fix for regression 305557
Comment on attachment 192420 [details] [diff] [review]
possible fix

a=dveditz for drivers for aviary101 and moz17 branches
Attachment #192420 - Flags: approval1.7.13+
Attachment #192420 - Flags: approval-aviary1.0.8+
(Assignee)

Comment 11

13 years ago
this fix looks like it's on the 1.7 branch and the 1.0x branch already. Am I missing something?
(Assignee)

Comment 12

13 years ago
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.
(Assignee)

Comment 13

13 years ago
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. 

Comment 14

13 years ago
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.
(Assignee)

Comment 15

13 years ago
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.

Comment 16

13 years ago
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 :)
(Assignee)

Comment 17

13 years ago
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?
(Assignee)

Comment 19

13 years ago
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?

Comment 20

13 years ago
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 :)
Status: RESOLVED → VERIFIED

Updated

13 years ago
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 21

13 years ago
my happy mouse clicks accidentally marked this bug as verified. re-opening, re-closing to get back to the fixed state without verification.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED
(Assignee)

Comment 22

13 years ago
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.
(Assignee)

Comment 23

13 years ago
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)
Group: security
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.