Hi all,

Messing around with the FTP part of curl 7.12.2, as used in
OpenOffice.org 2.0, I found the following two problems:

1 FTP URLs passed to curl may contain CR (0x0D) and LF (0x0A) in the
RFC 1738 <user>, <password>, and <fpath> components, either encoded as
"%0D" etc., or---in slightly illegal URLs---directly and unencoded.
These two characters are not allowd within RFC 959 <string>, for good
reason: <ftp://host/foo%0D%0Abar/...> leads to sending the two command
sequence

   CWD foo
   bar

to the server, which will complain about the "bar" garbage. A
quick-and-dirty patch to ftp.c 1.274 is attached.

2 FTP URLs passed to curl may contain NUL (0x00) in the RFC 1738
<user>, <password>, and <fpath> components, encoded as "%00". The
problem is that curl_unescape does not detect this, but instead returns
a shortened C string. From a strict FTP protocol standpoint, NUL is a
valid character within RFC 959 <string>, so the way to handle this
correctly in curl would be to use a data structure other than a plain C
string, one that can handle embedded NUL characters. From a practical
standpoint, most FTP servers would not meaningfully support NUL
characters within RFC 959 <string>, anyway (e.g., UNIX pathnames may not
contain NUL), so that a practical solution might be to add a check for
"%00" to curl_unescape and change the interface of that function, so
that it can report back on any "bad" input.

Note that both problems may probably hit curl for protocols other than
FTP, too.

-Stephan

(NB: Danile, re the recent "CURLOPT_PROXY and --disable-http" thread:
Yes, url.c 1.440 makes me happy. Thanks a lot.)
Received on 2005-01-19