Package: mime-support
Version: 3.60
Severity: normal
Dear Maintainer,
Please clarify how %-escapes in mailcap rules should be handled, because
RFC-1524 is unclear about it, and this is leading to differences in
implementations and security problems.
For example in gnu mailutils, you can do shell command injection form email
headers (bug #927836[1]):
# mailcap rule (shipped with debian):
text/html; /usr/bin/w3m -I %{charset} -dump -T text/html %s
# malicious header:
Content-Type: text/html; charset="$(rm -rf ~/*)"
In s-nail, they are planning[2] to pre-quote %-escapes expansions (kind of like
bash printf %q), and they are telling users not to add quotes around %-escapes
in mailcap rules because they would interfere with the automatic quotes in the
expansion.
This is a good solution, but quoted %-escapes in debian mailcap rules are
common, and they would break, for example:
text/plain; less '%s'; needsterminal
Please note that no amount of quotes in a mailcap rule can prevent command
injection (for example -I '%{charset}' could be exploited with charset="' & rm
-rf ~/* '").
RFC-1524 is unclear:
> The two characters "%s", if used, will be replaced by the name
> of a file for the actual mail body data. [...] Furthermore, any
> occurrence of "%t" will be replaced by the content-type and
> subtype specification. [...] A literal % character may be quoted
> as \%. Finally, named parameters from the Content-type field may
> be placed in the command execution line using "%{" followed by
> the parameter name and a closing "}" character. The entire
> parameter should appear as a single command line argument,
> regardless of embedded spaces.
The command is run by the bourne shell, which takes it as a single lump of
code, therefore the only way to fulfill that last condition ("The entire
parameter should appear as a single command line argument") is to pre-quote the
replacement (as s-nail is planning to do).
But that doesn't seem to be the common practice (well, my knowledge of the
common practice is limited because I managed to avoid mailcap since now).
Perhaps a less breaking solution would be to require implementers to filter out
*any* shell-special punctuation from the replacement of any mailcap %-escape.
Anyway, I think having a better definition here would provide a needed
guideline for programs using mailcap.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927836
[2]
https://manpages.debian.org/unstable/s-nail/s-nail.1.en.html#The_Mailcap_files
-- System Information:
Debian Release: 9.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
mime-support depends on no packages.
Versions of packages mime-support recommends:
ii bzip2 1.0.6-8.1
ii file 1:5.30-1+deb9u2
ii xz-utils 5.2.2-1.2+b1
mime-support suggests no packages.
-- no debconf information
