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

[Lyndon Nerenberg]

> On Oct 6, 2016, at 5:20 AM, David Levine <address@hidden> wrote:
> 
>> 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 think this is very wrong behaviour.

Filenames in the attachment meta-data are suggestions.  But they can be very 
valid suggestions, and shouldn't be ignored for arbitrary reasons.

But leading paths must be ignored, as security dictates.

The safest course of action is:

1) Take the basename of the suggested filename.

2) Perform an exclusive open+create of the filename.

2a) If the file exists, and we are interactive, prompt for a replacement name 
(or to overwrite); else (2c)

2b) If the as-encoded filename results in an error from the underlying open() 
call, report the error and fall through.

2c) Synthesize a unique name, write to that, and report the name.

--lyndon