176016 - Sending an email can reveal the name of the profile directory secret .slt name, the username, or hostname

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect)

Description

[Nicolas Pioch]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2a) Gecko/20020926
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.2a) Gecko/20020926

Quoting from http://mozilla.org/releases/mozilla1.2b/#problems

Your profile directory is located at:
    * ~/.mozilla/<profilename>/xxxxxxxx.slt/ on Unix
    * %WINDOWS%\Application Data\Mozilla\Profiles\<profilename>\xxxxxxxx.slt\ on
Windows
    * Documents:Mozilla:Profiles:<profilename>:xxxxxxxx.slt: on Mac OS.
  xxxxxxxx.slt is a randomly generated directory name. It's an important
security feature.

Well, if I print an email (either to a shared printer in an office/university,
or if I fax the email using Print and select a FAX printer,
of if I save/export the email as Acrobat/PDF using Print to PDF printer)

in the upper right corner of the printout, my "important security feature"
is revealed for anyone to read, with the full pathname to the user profile
folder, such as:

  mailbox:///C|/Docs/Users/pioch/h3iu39d3.slt/Mail/Local%20Folders/Inbox

This is not the place to debate security through obscurity
(I sure hope that it's not sufficient to find the name of the .slt directory
to hack into my machine) but there is one consistency problem here.

Either "this is an important security feature" as indicated in the release
notes, and it should be kept secret, or it is not, and the Release Notes/
official talk should know better?


Reproducible: Always

Steps to Reproduce:
1. Display any email stored locally (Local Folders)
2. Select File | Print, or Print Preview to view on-screen
3. Look in upper right corner

Actual Results:  
"Secret" profile name randomly generated xxxxxx.slt
"important security feature" is for all to read

Expected Results:  
Mailbox URLs should not print full path.
Maybe it could be assumed that everything is under the Mail directory
in the user profile, so

mailbox://Local%20Folders/Inbox

should be sufficient.

Comment 1

[Nicolas Pioch]

BTW, I know you can go into "Print Setup" and disable printing the URL
in the upper right corner.

However you usually do want the URL when you are printing a web page,
but you don't want it when it includes the .slt security feature.

Having to reconfigure Print Setup every time you print to avoid leaking
confidential information isn't exactly the most convenient or secure solution...

it's like having to reconfigure your Internet firewall every time you change
application :-)

Comment 2

[John Unruh]

Coonfirming. With local mail folders, and a short path to them, the full path
can be displayed at the top of the page.

Comment 3

[John Unruh]

Printing

Comment 4

[Nicolas Pioch]

Instead of printing
  mailbox:///C|/Docs/Users/pioch/h3iu39d3.slt/Mail/Local%20Folders/Inbox

there is already a URI scheme available that wouldn't reveal that much information:

  mailbox-message://nobody@Local Folders/Inbox#9219938

PS: I hope that for IMAP accounts the "nobody@" doesn't get replaced with your
IMAP login (this would leak information again, especially when you attach such
an email to forward it appended to another message)

Comment 5

[Kevin McCluskey (gone)]

This looks like an issue for mail, not the printing back end. Mail needs to
disable printing of the URL when it specifies the print options.

Comment 6

[(not reading, please use [e-mail] instead)]

re-assigning nsbeta1+ bugs

Comment 7

[Nicolas Pioch]

Disabling printing the URL when printing is not sufficient:

If you drag and drop an image embedded inside an email you received
into an email you are composing (Compose Window) in the attachment area,
when you send out the email the .slt profile name is leaked once again:

Here are what the MIME headers look like:

Content-Type: image/jpeg;
 name="mailbox:///C|/Users/pioch/j8217hdt.slt/Mail/Local%20Folders/Lists?number=7852747&part=1.4&type=image/jpeg&filename=sit_2.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="mailbox:///C|/Users/pioch/j8217hdt.slt/Mail/Local%20Folders/Lists?number=7852747&part=1.4&type=image/jpeg&filename=sit_2.jpg"

Comment 8

[Samir Gehani]

Mail triage team: need info.  Mitch, can you comment on the security
impliciations of this bug and the priority to fix this for Buffy?  Thanks.

Comment 9

[Mitchell Stoltz (not reading bugmail)]

Do we reveal the profile path when _sending_ an email? If so, I would consider
this serious and a stop-ship. If this only happens during printing, it's less
serious, a "would like to have" for Buffy.

Reporter, the profile directory "salt" is an important feature that prevents
certain historical attacks against the information in your profile directory.
However, simply knowing the salt will not allow an attacker to access that
information; there are other lines of defense.

Comment 10

[Nicolas Pioch]

Yes, I'm aware of the histerical attacks against prefs.js
(in Netscape 4, overloading the user_pref() or lock_pref() javascript
function and loading prefs.js :-)

Make it a stop-ship then.

I opened this bug for printing/faxing then found out the .slt
was also leaked when sending an email, read comment 7 above
on how to reproduce.

Let me know if this isn't clear enough and I'll detail more how
drag'n'drop'ing an embedded image (cid:) from an email you received
into an email you're composing reveals your .slt profile name
in the MIME headers to the email recipient.

Comment 11

[Nicolas Pioch]

Just sent an email to myself according to the process described in comment 7
with Mozilla/1.3 Windows2000

and verified the .slt profile directory is still present in the MIME headers
of the message as received.

Comment 12

[Mitchell Stoltz (not reading bugmail)]

OK, let's get this fixed for Buffy.

Comment 13

[Rafael Ebron (:rebron)]

Mail triage: nsbeta1+/adt1

Comment 14

[(not reading, please use [e-mail] instead)]

"printing/faxing" is fixed in bug #118887

keeping this open for any sending issues.

Comment 15

[(not reading, please use [e-mail] instead)]

Attachment: patch

prevent leakage of mail uris or urls that might reveal hostname, username, or
.slt path.

Comment 16

[(not reading, please use [e-mail] instead)]

fixed, you should not longer be able to leak local, imap, or news message uris
or urls.

at least, I've plugged the printing/faxing hole, and now the message attach hole.

if we find other holes, I'll plug them too.

Comment 17

[(not reading, please use [e-mail] instead)]

now when you dnd message parts or messages, the pretty name will be:

Attached Message
or
Attached Message Part

defined in composeMsgs.properties

Comment 18

[(not reading, please use [e-mail] instead)]

robinf / esther / nbaca:  any better suggestion for the UI strings?

Comment 19

[esther]

Using trunk build 20030515 on winxp, mac and linux printing mail messages from
imap folders, local folders no longer shows the location string at the top of
the printed page.  Dragging an image off a message to a compose window does not
show the location of where the message with the image is located.   It shows
Attached Message Part. Verified.