Bug 134133

Summary: Proposed workaround for SSL auth in ProFTPD
Product: [Fedora] Fedora Reporter: Aleksandar Milivojevic <alex>
Component: curlAssignee: Eido Inoue <havill>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 7.12.1-1 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-06 19:58:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Workaround for brain damaged secure FTP servers none

Description Aleksandar Milivojevic 2004-09-29 19:20:22 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914
Firefox/0.10

Description of problem:
ProFTPD has a design flaw that USER/PASS commands must always be
executed for user to log in, even when passwords are not used to
authenticate users.  This makes a problem if some other mean of
authentication is implemented (for example, user is autheticated using
SSL/TLS).  In this case, instead of returning 232 for USER command,
ProFTPD will return 331, and after client sends empty PASS command, it
will return code 232 (instead of expected 230).

Debugging output looks like this:

$ curl -E ~/usercert.pem --ftp-ssl -v ftp://username@foobar.com/
* About to connect() to foobar.com port 21
* Connected to foobar.com (192.168.1.1) port 21
< 220 FTP Server ready.
> AUTH SSL
< 234 AUTH SSL successful
Enter PEM pass phrase:
* successfully set certificate verify locations:
*   CAfile: /usr/share/ssl/certs/ca-bundle.crt
  CApath: none
* SSL connection using EDH-RSA-DES-CBC3-SHA
* Server certificate:
   [cert details deleted, not relevant]
> USER username
< 331 Password required for username.
> PASS
< 232 User username logged in.
* Odd return code after PASS
* Closing connection #0
curl: (11) Odd return code after PASS

Included is a simple patch to work around this issue.

Version-Release number of selected component (if applicable):
curl-7.11.1-1

How reproducible:
Always

Steps to Reproduce:
1. Connect to FTP server using SSL authentication


Additional info:
Comment 1 Aleksandar Milivojevic 2004-09-29 19:21:47 UTC 
Created attachment 104540 [details]
Workaround for brain damaged secure FTP servers
Comment 2 Eido Inoue 2004-09-30 18:26:01 UTC 
Please explain to me why curl should be patched as opposed to ProFTD?
Is this change standards compatible (ie won't break any real or
theoretical fully compliant ftp server out there)?
Comment 3 Aleksandar Milivojevic 2004-09-30 19:44:21 UTC 
Curl should be patched in order to work with existing ProFTPD servers
(even after ProFTPD is patched).  There is huge installed base of
ProFTPD servers out there.  Also, it is not likely that ProFTPD will
be patched soon, because the bug is in the design of ProFTPD's
authentication module.  It's not just a couple of lines of code, it
needs to be revised, and possible other modules that depend on current
desing of auth module.  I've checked ProFTPD source and their bug
tracking web page.  It seems developers are aware of the problem, but
there is no easy way to fix it.  This workaround would enable curl to
interoperate with current ProFTPD servers, until the bug in ProFTPD is
fixed.

The change is compatible.  It should not break any real or
theretically fully compliant ftp server out there becase:

 - Fully compliant FTP server will not require PASS command (it will
return 232 as response to USER command, as defined in RFC 2228 and
proposed standard described in draft-murray-auth-ftp-ssl-15.txt). 
Also, code 232 is not mentioned anywhere in RFC 959, so any "plain
old" FTP server should never return it as response to any command.

 - Codes 2xx are reserved for positive completitions, so anything 2xx
means server accepted the password and does not expect any further
information (otherwise, it would issue 3xx if more information was
needed, 4xx or 5xx in case of errors).  I am not aware of any servers
sending 2xx as response to PASS when they should send 3xx.  Even if
there are any, they wouldn't work with existing checks in curl anyhow
(if I haven't missed something obvious in curl's source).
Comment 4 Daniel Stenberg 2004-10-01 12:19:25 UTC 
I would suggest you report problems/bugs/patches in curl to the curl
project first.

I have now modified the PASS response code check in curl, included in
the upcoming 7.12.2 release.
Comment 5 Aleksandar Milivojevic 2004-10-01 16:35:58 UTC 
Thanks.  I'll keep that in mind for future.