Package: mailcap Version: 3.68 Tags: security Dear Maintainer,
run-mailcap is vulnerable to shell command injection in its input data. Specifically, commands can be injected into a MIME type name, a charset name, or other data originating from a Content-Type header. If run-mailcap is used by some mail program or script for mailcap support, then a malicious message can cause the execution of arbitrary shell code just by being displayed. (Test with --norun, at your own risk.) -- rule text/*; /usr/bin/w3m -T %t %s -- exploit $ type='text/$(rm -fr *)' # e.g. from a malicious mail header $ run-mailcap --action=view "$type":filename -- rule text/html; /usr/bin/w3m -I %{charset} %s -- exploit $ charset="'\$(rm -fr *)'" # e.g. from a malicious mail header $ charset=$charset run-mailcap --action=view filename.html The solution is to have run-mailcap properly quote any string that is going to be the result of a %-expansion. Currently, single quotes are introduced around expansions, but they are useless because nothing is done for the single quotes already occurring *within* the expansions. Then, the resulting command is processed in an attempt to remove excessive single quotes, which is ugly because it can break perfectly valid code while adding no security (at this point legitimate code is indistinguishable from injected code). I recommend to get rid of the single quotes handling part and just add a backslash before each whitespace or shell-special punctuation in the expansion. Example: it's unsafe -> it\'s\ unsafe Shell-special punctuation characters are: !"#$&'()*;<>?[\]`{|}~ With this solution: - correct rules always work; - overquoted rules (a common error) work if the expansion is limited to safe characters; - overquoted rules with unsafe characters may not work, but command injection is always prevented. The problem was already reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928037#27 Sorry for not having a patch but I'm not familiar with perl. I've also found several edge cases where run-mailcap behavior is nonstandard and unexpected, but they are not about command injection so I'll file a separate bug if I find the time. The main problem is that run-mailcap tries to emulate a finite state machine by performing a sequence of replacements, without the necessary attention to get it right (e.g. finding quoted semicolons by searching for '\;' may seem like a good idea, but a semicolon preceded by an even number of backslashes is *not* quoted). Thanks, MNZ