Ftp-WG: Re: UTF-8 pathnames: pathname nature & length

> The draft therefore precludes the use of some control characters
> such as tab, bell, backspace, CR, LF as part of pathname
> constituent characters.  The use of such characters in the
> native pathnames may be strange, but should not be excluded
> by a FTP server complying to the draft.  One example is
> Linux on which a file "abc^Gdef.txt" (read as "abc" control-G
> "def.txt") is created on-purpose (perhaps to give a sound for
> that important file), or accidentally (perhaps due to telnet
> terminal/dial-up mess-ups).  The user logins in via FTP but the
> complying FTP server cannot send the filename because ^G is
> not a valid pathname, and user cannot delete the file because
> a complying client cannot send the filename.
>
> For that reason, I tend to agree with RFC2640 more.

You would be wrong.

Consider: what will you do when you send a pathname containing the ASCII DEL
character, such as:

RETR myfile(%x7F)DELE myfile

where (%x7F) is the DEL character.

A compliant FTP server which implements command editing, as it is
*specifically* allowed to do by RFC 959, could interpret the DEL as "erase
line".

That RETR command isn't a RETR command, it's a DELE command.

The black-hats love this sort of mistake.

> In addition, I think it's a good thing that the draft examines
> security more closely regarding the impact of misinterpreting
> UTF-8 encodings.  It may be also in scope to look at the length
> restriction on any submitted UTF-8 pathnames from client
> to server, and any UTF-8 pathname responses from server to
> client.

Traditionally, the FTP does not inherently imply any length restrictions.

> The draft recognises that there are multiple lengths of
> encodings for a given UCS4 character (though I don't really
> see how if one sticks to the UCS4-->UTF8 encoding by range,
> and rejects invalid UTF8 encodings during UTF8-->UCS4
> translations).

The black-hats, of course, don't particularly care about "rules".

Also, neophites can mis-code the routine.  It's real easy to just punt and
use the 6-byte (longest-possible) UTF-8 encoding for everything.

>  Regardless, there may be a need to define
> a maximum number of bytes for the UTF-8 encoded pathname
> so that servers and clients can allocate relevant amount
> of resources (eg. memory) to handle UTF-8 pathname processings
> when they comply to the draft.  Beyond the stated maximum
> number of bytes, the pathname is categorically considered
> invalid.  The purpose is primarily to prevent the exploitation
> through overflowing of buffers or memory/CPU resource abuse by
> sending lengthy pathnames.

Nah.  Let the server decide its own maximum length and 501 the command if it
does not like it.  Similarly, the client can discard/truncate any reply
which exceeds the length.

Put another way: once we set a limit (N), the OS vendors will start allowing
pathnames which are (N+1) long.