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

On Tue, 21 May 2002, Gregory A Lundberg wrote:

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

If that "specifically" is the:

--- 8< ---
   5.2.  CONNECTIONS

      The server protocol interpreter shall "listen" on Port L.  The
      user or user protocol interpreter shall initiate the full-duplex
      control connection.  Server- and user- processes should follow the
      conventions of the Telnet protocol as specified in the
      ARPA-Internet Protocol Handbook [1].  Servers are under no
      obligation to provide for editing of command lines and may require
      that it be done in the user host.  The control connection shall be
      closed by the server at the user's request after all transfers and
      replies are completed.

--- >8 ---

...then it's the most stretched out interpretation of this text possible.
Nowhere in the text it's even mentioned, what kind of editing is allowed
(terminal-like? GNU readline? autocompletion? interpretation of telnet EC
and EL sequences?), so it's pretty safe to assume that it's none. Telnet
protocol itself only defines EC ("erase character") and EL ("erase line"),
and both of them are escaped commands, as opposed to single characters.

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

  It's RETR. What user can or can't enter on the keyboard using any kind
of command line editing locally on his end, is irrelevant, only what is
passed over the connection matters.

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

  OS however usually does.

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

 Black hats shouldn't matter at all -- if the standard is unambiguous, no
problems would happen, no matter what is actually passed over the line.

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

  Neophytes can mis-code "hello, world".

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

  Even though my objections to UTF-8-ization of FTP and proposals to
declare binary transparency, as telnet does, and leave this "problem"
alone, fell on the deaf ears here, I am happy that for many years this
group is developing unusable standard modifications that no one is going
to use -- de-facto standard is to just ignore obsolete ASCII-only
requirement for filenames, and it works just fine, thank you very much.

-- 
Alex