[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Earl Hood
Subject: Re: [Nmh-workers] RFC 2047 vs RFC 2231 encoding for MIME parameters
Date: Wed, 5 Oct 2016 22:49:32 -0500

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]