files are not attached at *attachment time*, but *LATER* (during send) - should create and use tmp copy of file immediately when attaching

RESOLVED DUPLICATE of bug 378046

Status

MailNews Core
Import
--
major
RESOLVED DUPLICATE of bug 378046
15 years ago
9 years ago

People

(Reporter: L A Walsh, Assigned: Scott MacGregor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
User-Agent:       lynx 5.5 (vision impaired version)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916

Attached a file to my email.  wasn't finished composing yet, needed
to do more testing....testing overwrote file that I had already
attached.

Later, hit SEND, and it either (1) sends wrong file contents (if file
contents were replaced after attachment but before send) or (2) says
file doesn't exist (if file deleted after attachment and before send).

Either way this is a nasty bug, with possible unintentional security
leakage -- i.e. if file has been replaced with new contents that contain
sensitive info, you just accidently released the sensitive info --
even though the file didn't contain the info when you attached it.

Reproducible: Always

Steps to Reproduce:
1. attach file with text "boring text" in it.
2. modify file, add your checking account statement to it! :-)
3. send email; the recipient gets your checking account statement instead
of just "boring text"


Actual Results:  
wrong file got sent in 1 case, in another was flagged with error that 
file didn't exist when I hit send -- shouldn't matter, I already "attached"
the file and it should store it somewhere as a separate copy.

Expected Results:  
should copy attached file into tmpdir/mozilla-tmpname-xxxxxx when attached, so 
user isn't surprised.  It's like the modern "lp/print" systems -- they make a
copy of the file being submitted for print, so if user deletes or edits file
afterwards, before file is actually printed from queue, it doesn't alter the
output -- they still get the file they queued for printing (or in this case,
attached for sending) in the final output...
Confrming, WinXP, Moz 1.5.

I've also noticed/suspected this, but didn't complain 'cos I kind of found this
useful. Namely, I attached a file, edited the file some more, then hit send.
However, this IS a small security issue.

Before actually fixing this, we should also see what other mail agents do. What
do Outlook, Eudora, Pine, (your other favorite email program) do?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

15 years ago
guessing this should go from cavin -> mscott, bienvenu, ssptizer at this point.
 not sure this is really a security bug...   attachments should be made when the
file is ready to go would be the behavor that most people observe and expect I
would think
Assignee: cavin → mscott
(Assignee)

Comment 3

15 years ago
this is by design. we have always done it this way. So has 4.x
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID
Group: security
Product: MailNews → Core
Product: Core → MailNews Core
There are several duplicate bugs that request the same. Furthermore, things have changed over time since 2003... There's Bug 378046 around the same problem and it has been confirmed, so this can no longer be invalid. And, there's some agreement among developers in bug 378046 that "always take a snapshot" at attachment time should be the starting point for fixing the respective bugs, including this one --> duplicate of bug 378046.

btw the fact that "we have always done it this way since 4.x" surely doesn't mean that things couldn't or shouldn't change, otherwise there'd be no evolvement at all...
OS: Windows XP → All
Hardware: x86 → All
Resolution: INVALID → DUPLICATE
Summary: files not attached at *attachment time* -- but attached *LATER* (during send) → files are not attached at *attachment time*, but *LATER* (during send) - should create and use tmp copy of file immediately when attaching
Duplicate of bug: 378046
You need to log in before you can comment on or make changes to this bug.