While reading this bug report http://dev.mutt.org/trac/ticket/3400 about
lack of documentation for the mailto: support, and reading the current
security warning about use of mailto:, I came to the conclusion that the
current method is insecure.
This patch adds two new commands:
mailto_allow header-field [...]
unmailto_allow [ * | header-field ... ]
which control a whitelist of allowed header fields that Mutt will
process from a mailto: URL. By default only "subject" and "body" are on
the list, as specified by RFC2368.
me
diff -r 25e12863c521 doc/manual.xml.head
--- a/doc/manual.xml.head Sat Apr 03 07:35:39 2010 -0700
+++ b/doc/manual.xml.head Sat Apr 03 11:34:13 2010 -0700
@@ -4625,6 +4625,37 @@ set index_format="%4C %Z %{%b %d} %-15.1
</sect2>
+</sect1>
+
+<sect1 id="mailto-allow">
+<title>Control allowed header fields in a mailto: URL</title>
+
+<para>Usage:</para>
+
+<cmdsynopsis>
+<command>mailto_allow</command>
+<group choice="req">
+<arg choice="plain">
+<replaceable class="parameter">*</replaceable>
+</arg>
+<arg choice="plain" rep="repeat">
+<replaceable class="parameter">header-field</replaceable>
+</arg>
+</group>
+</cmdsynopsis>
+
+<para>
+As a security measure, Mutt will only add user-approved header fields from a
+<literal>mailto:</literal> URL. This is necessary since Mutt will handle
+certain header fields, such as <literal>Attach:</literal>, in a special way.
+The <literal>mailto_allow</literal> and <literal>unmailto_allow</literal>
+commands allow the user to modify the list of approved headers.
+</para>
+<para>
+Mutt initializes the default list to contain only the
<literal>Subject</literal>
+and <literal>body</body> header fields, which are the only requirement
specified
+by the <literal>mailto:</literal> specification in RFC2368.
+</para>
</sect1>
</chapter>
diff -r 25e12863c521 doc/muttrc.man.head
--- a/doc/muttrc.man.head Sat Apr 03 07:35:39 2010 -0700
+++ b/doc/muttrc.man.head Sat Apr 03 11:34:13 2010 -0700
@@ -399,6 +399,16 @@ This command will remove all hooks of a
This command will remove all hooks of a given type, or all hooks
when \(lq\fB*\fP\(rq is used as an argument. \fIhook-type\fP
can be any of the \fB-hook\fP commands documented above.
+.PP
+.nf
+\fBmailto_allow\fP \fIheader-field\fP [ ... ]
+\fBunmailto_allow\fP [ \fB*\fP | \fIheader-field\fP ... ]
+.fi
+.IP
+These commands allow the user to modify the list of allowed header
+fields in a \fImailto:\fP URL that Mutt will include in the
+the generated message. By default the list contains only
+\fBsubject\fP and \fBbody\fP, as specified by RFC2368.
.SH PATTERNS
.PP
In various places with mutt, including some of the above mentioned
diff -r 25e12863c521 globals.h
--- a/globals.h Sat Apr 03 07:35:39 2010 -0700
+++ b/globals.h Sat Apr 03 11:34:13 2010 -0700
@@ -159,6 +159,7 @@ WHERE LIST *InlineExclude INITVAL(0);
WHERE LIST *InlineExclude INITVAL(0);
WHERE LIST *HeaderOrderList INITVAL(0);
WHERE LIST *Ignore INITVAL(0);
+WHERE LIST *MailtoAllow INITVAL(0);
WHERE LIST *MimeLookupList INITVAL(0);
WHERE LIST *UnIgnore INITVAL(0);
diff -r 25e12863c521 init.c
--- a/init.c Sat Apr 03 07:35:39 2010 -0700
+++ b/init.c Sat Apr 03 11:34:13 2010 -0700
@@ -3021,6 +3021,15 @@ void mutt_init (int skip_sys_rc, LIST *c
mutt_init_history ();
+ /* RFC2368, "4. Unsafe headers"
+ * The creator of a mailto URL cannot expect the resolver of a URL to
+ * understand more than the "subject" and "body" headers. Clients that
+ * resolve mailto URLs into mail messages should be able to correctly
+ * create RFC 822-compliant mail messages using the "subject" and "body"
+ * headers.
+ */
+ add_to_list(&MailtoAllow, "body");
+ add_to_list(&MailtoAllow, "subject");
diff -r 25e12863c521 init.h
--- a/init.h Sat Apr 03 07:35:39 2010 -0700
+++ b/init.h Sat Apr 03 11:34:14 2010 -0700
@@ -3485,6 +3485,8 @@ struct command_t Commands[] = {
{ "macro", mutt_parse_macro, 0 },
{ "mailboxes", mutt_parse_mailboxes, M_MAILBOXES },
{ "unmailboxes", mutt_parse_mailboxes, M_UNMAILBOXES },
+ { "mailto_allow", parse_list, UL &MailtoAllow },
+ { "unmailto_allow", parse_unlist, UL &MailtoAllow },
{ "message-hook", mutt_parse_hook, M_MESSAGEHOOK },
{ "mbox-hook", mutt_parse_hook, M_MBOXHOOK },
{ "mime_lookup", parse_list, UL &MimeLookupList },
diff -r 25e12863c521 url.c
--- a/url.c Sat Apr 03 07:35:39 2010 -0700
+++ b/url.c Sat Apr 03 11:34:14 2010 -0700
@@ -282,28 +282,43 @@ int url_parse_mailto (ENVELOPE *e, char
if (url_pct_decode (value) < 0)
return -1;
- if (!ascii_strcasecmp (tag, "body"))
+ /* Determine if this header field is on the allowed list. Since Mutt
+ * interprets some header fields specially (such as
+ * "Attach: ~/.gnupg/secring.gpg"), care must be taken to ensure that
+ * only safe fields are allowed.
+ *
+ * RFC2368, "4. Unsafe headers"
+ * The user agent interpreting a mailto URL SHOULD choose not to create
+ * a message if any of the headers are considered dangerous; it may also
+ * choose to create a message with only a subset of the headers given in
+ * the URL.
+ */
+ if (mutt_matches_ignore(tag, MailtoAllow))
{
- if (body)
- mutt_str_replace (body, value);
- }
- else if ((taglen = mutt_strlen (tag)) <= sizeof (scratch) - 2)
- {
- /* only try to parse if we can format it as header for
- * mutt_parse_rfc822_line (tag fits in scratch) */
- snprintf (scratch, sizeof (scratch), "%s: %s", tag, value);
- scratch[taglen] = '\0';
- value = &scratch[taglen+1];
- SKIPWS (value);
- mutt_parse_rfc822_line (e, NULL, scratch, value, 1, 0, 0, &last);
- }
- else
- {
- rc = -1;
- goto out;
+ if (!ascii_strcasecmp (tag, "body"))
+ {
+ if (body)
+ mutt_str_replace (body, value);
+ }
+ else if ((taglen = mutt_strlen (tag)) <= sizeof (scratch) - 2)
+ {
+ /* only try to parse if we can format it as header for
+ * mutt_parse_rfc822_line (tag fits in scratch) */
+ snprintf (scratch, sizeof (scratch), "%s: %s", tag, value);
+ scratch[taglen] = '\0';
+ value = &scratch[taglen+1];
+ SKIPWS (value);
+ mutt_parse_rfc822_line (e, NULL, scratch, value, 1, 0, 0, &last);
+ }
+ else
+ {
+ rc = -1;
+ goto out;
+ }
}
}
+ rc = 0;
out:
FREE (&tmp);
return rc;
Attachment:
pgpMZBYcNoPKI.pgp
Description: PGP signature