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

[David Levine]

Earl wrote:

> 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 security reasons, this filename will be ignored if it begins
    with the character '/', '.', '|', or '!', or if it contains the
    character '%'.

> For example, what if I have:
>
>   Content-Type: application/octet-stream
>   Content-Disposition: attachment; filename="/etc/passwd"
>
> or relative pathname attacks using "../.."?

The /etc/passwd or relative pathanme will be ignored, and a name of
the form message#.part#.subtype will be used instead (assuming no
profile override).

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

It can, starting with 1.6, using the mhstore(1) -clobber switch.

> 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.

Yup, we're there.  The mhstore switch you refer to is -auto; the
default is -noauto.

mhstore also has an -outfile switch, so the user can specify a
particular filename (to store all selected content).

David