# Re: Predraft of a new URL scheme: mailmsg

Ned Freed (NED@SIGURD.INNOSOFT.COM)
Wed, 04 Jan 1995 16:35:55 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ronald E. Daniel: "Re: Library Standards and URIs"
- Previous message: Michael Shapiro: "Re: Library Standards and URIs"
- Maybe in reply to: Paul Hoffman: "Predraft of a new URL scheme: mailmsg"
- Next in thread: Larry Masinter: "Re: Predraft of a new URL scheme: mailmsg"
- Reply: Larry Masinter: "Re: Predraft of a new URL scheme: mailmsg"

    Date: Wed, 04 Jan 1995 16:35:55 -0700 (PDT)

    From: Ned Freed <NED@SIGURD.INNOSOFT.COM>

    Subject: Re: Predraft of a new URL scheme: mailmsg

    In-Reply-To: Your message dated "Wed, 04 Jan 1995 11:55:33 -0800 (PST)"

    To: Larry Masinter <masinter@parc.xerox.com>

    Message-Id: <01HLGEPYUJ7Y9BVKUU@SIGURD.INNOSOFT.COM>

> I've realized that the 'security hole' we've identified with the
> proposed 'mailmsg' URL scheme exists also for use of the
> message/external-body, but RFC1521 doesn't call it out particularly.

I'm ahead of you on this one... I had already written prose to deal with this
issue for the next revision of the MIME specification. There is also a related
issue that needed to be addressed, which the prose covers. Here's what the new
section says (forgive the NROFF formatting, I'm in a hurry):

.\" .bp
.sh 5 "External-Body Security Issues"
.lp
Message/external-body entities give rise to two important security issues:
.np
Accessing data via a message/external-body reference effectively results in the
message recipient performing an operation that was specified by the message
originator. It is therefore possible for the message originator to trick a
recipient into doing something they would not have done otherwise. For example,
an originator could specify a action that attempts retrieval of material that
the recipient is not authorized to obtain, causing the recipient to unwittingly
violate some security policy. For this reason, user agents capable of resolving
external references must always take steps to describe the action they are to
take to the recipient and ask for explicit permisssion prior to performing it.
.sp
The 'mail-server' access-type is particularly vulnerable, in that it causes the
recipient to send a new message whose contents are specified by the original
message's originator. Given the potential for abuse, any such request messages
that are constructed should contain a clear indication that they were generated
automatically (e.g. in a Comments: header field) in an attempt to resolve a
MIME message/external-body reference.
.np
MIME will sometimes be used in environments that provide some guarantee of
message integrity and authenticity. If present, such guarantees may apply only
to the actual direct content of messages -- they may or may not apply to data
accessed through MIME's message/external-body mechanism. In particular, it
may be possible to subvert certain access mechanisms even when the messaging
system itself is secure.
.sp
It should be noted that this problem exists either with or without the
availabilty of MIME mechanisms. A casual reference to an FTP site containing
a document in the text of a secure message brings up similar issues -- the
only difference is that MIME provides for automatic retrieval of such material,
and users may place unwarranted trust is such automatic retrieval mechanisms.

> I don't think that we should shirk dealing with security considerations
> in URL schemes, but rather, we might expect RFC1521 to expand the
> security consideration section to address the issue of possible
> mail-spoofing in message/external-body messages, e.g.:

> ================================================================
> Content-Type: message/external-body; access-type=mail-server
> Server="president@whitehouse.gov"

> Content-type: text/plain
> Content-ID: <666@devil.org>

> Insert generic death threat here.
> ================================================================

I agree 100%, and while I did try to avoid the inclusion of an example as
specific as this one (given recent events on the front lawn at 1600
Pennsylvania, this is more inappropriate than ever), I did try to cover all
this in the new text.

I note in passing that there is another issue with URLs that probably should be
dealt with -- I once saw a URL that pointed at 127.0.0.1 and was attached to
the chargen port. The effect of resolving this URL was to fill the spool area
up completely in very short order (since the transfer occurred at system
speeds, not network speeds), and that brought the entire system to its knees.

I don't recall whether or not this is mentioned in the URL specification. If
not, it probably should be, and a list of standard ports to shun should
probably be added.

Ned

- Next message: Ronald E. Daniel: "Re: Library Standards and URIs"
- Previous message: Michael Shapiro: "Re: Library Standards and URIs"
- Maybe in reply to: Paul Hoffman: "Predraft of a new URL scheme: mailmsg"
- Next in thread: Larry Masinter: "Re: Predraft of a new URL scheme: mailmsg"
- Reply: Larry Masinter: "Re: Predraft of a new URL scheme: mailmsg"