Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters

[Earl Hood]

On Tue, Oct 4, 2016 at 7:44 AM, Ralph Corderoy wrote:

>     Content-Type: inode/x-empty; name*=UTF-8''%41%00%42
>     Content-Disposition: attachment; filename*=UTF-8''%41%00%42
>
> `mhstore -auto' creates `./A'.  Perhaps the RFCs rule out %00?  But then
> again, we're talking about crap that doesn't follow the RFCs.  If it's
> %41%2F%42 then `A/B' is created if A exists, so that seems OK.

It not okay.  Filenames specified in email is considered informative only
since there are security implications of blindly using what is provided.

For any file nmh creates based on email parameter input, it should run it
through a sanitizer to remove any characters deemed invalid and remove any
pathname components.  For example, what if I have:

  Content-Type: application/octet-stream
  Content-Disposition: attachment; filename="/etc/passwd"

or relative pathname attacks using "../.."?

I do not recall if nmh checks if a file with same name already exists.

If we are to be security conscience, filename parameter should be ignored,
with files stored based on content-type, or at a minimum, just use the
filename parameter extension.  An option can be provided to specify that the
filename parameter be honored, but even then, only use the basename after it
has been sanitized.

--ewh