This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: mimetools module privacy leak
Type: Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: barry Nosy List: barry, phr
Priority: normal Keywords:

Created on 2002-07-12 09:35 by phr, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (3)
msg11538 - (view) Author: paul rubin (phr) Date: 2002-07-12 09:35
The mimetools "choose_boundary" function according to
its doc
returns a string of the form
'hostipaddr.uid.pid.timestamp.random'.
If this separator is actually used in a message, it
reveals the host ID
and UID of the sender.  This is a privacy breach
similar to the discovery
that Microsoft Word files contained user GUID's
revealing the user's
PC's ethernet card's MAC address (since fixed, after
the story was
published on the front page of the New York Times about
2 years ago).
Some info is at

  http://www.junkbusters.com/microsoft.html#advisory


The fix for choose_boundary is to make the boundary
string completely
random and not have it reveal personal information
about the user.
msg11539 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2002-08-06 16:22
Logged In: YES 
user_id=12800

Is this a serious concern for most applications?  In most
email messages, some identifying information will always
leak so since it takes work to anonymize messages anyway, an
application with these concerns can simply implement its own
choose_boundary() algorithm, or lop off the hostid part of
the generated one.

Besides, mimetools.py should be considered obsolete, in
favor of the email package.  When it generates a boundary it
doesn't include any identifying information (but has a
moderately higher possibility of collision in the source text).
msg11540 - (view) Author: paul rubin (phr) Date: 2002-08-07 02:30
Logged In: YES 
user_id=72053

On the occasions where the leak matters, the consequences
can be serious.

Think of an AOL user with a screen name that she uses for
work-related email, and a
separate screen name she uses to post to a mail list for
sufferers of sexually transmitted diseases.
If she sends a file attachment to a co-worker from the work
screen name, and a different attachment
to the STD list from the personal screen name, and her mail
client uses mimetools.py, a co-worker looking at the STD
mailing list's web archive can see that both attachments
came from the same person.

Former US Navy Senior Chief Petty Officer Tim McVeigh (not
related to the OKC bomber with the
same name) had his Navy career destroyed over something sort
of like this (he had an anonymous AOL profile revealing that
he was gay, and the Navy connected it to him).  Although
McVeigh stayed out of jail because a Federal judge ruled
that the Navy had violated the DoD "don't ask, don't tell,
don't pursue" policy by contacting AOL to find his identity,
if he had used mimetools.py to send file attachments like
the hypothetical person above, the Navy might have gotten
the two MIME separators without having to specially contact
anyone, and so McVeigh could possibly be in the slammer now.

Anyway, if mimetools.py is deprecated, the manual should be
updated to say so.  It wouldn't have occurred to me to not
use it if I wanted to send a MIME message.  The docs should
also mention this privacy leak.  But I think it's better to
just fix it.
History
Date User Action Args
2022-04-10 16:05:30adminsetgithub: 36882
2002-07-12 09:35:38phrcreate