Mac OS X 10.5.8 Security Update 2010-002 breaks curl ftp support

Originator:mackyle
Number:rdar://7810450 Date Originated:30-Mar-2010 03:32 PM
Status:Closed Resolved:Won't Fix
Product:Mac OS X Product Version:10.5.8/9L30
Classification:Serious Bug Reproducible:Always
 
SUMMARY

Prior to the Mac OS X 10.5.8 Security Update 2010-002, when curl was used with an ftp server, if sending the USER command resulted in a successful login (230 response) it did not send the PASS command.  As of Security Update 2010-002, curl sends the PASS command regardless of whether or not the USER command results in a successful login.

This breaks access to some devices (brother printer/scanner) that provide ftp access and login with the USER command but do not implement the PASS command.

STEPS

The following assumes you have a Brother MFC-495CW printer/scanner located at IP address 172.16.16.85.

1. Issue this curl command:

/usr/bin/curl -v -I ftp://172.16.16.85/

2. Observe the output:

* About to connect() to 172.16.16.85 port 21 (#0)
*   Trying 172.16.16.85... connected
* Connected to 172.16.16.85 (172.16.16.85) port 21 (#0)
< 220 FTP print service:V-1.13/Use the network password for the ID if updating.
> USER anonymous
< 230 User anonymous logged in.
> PASS ftp@example.com
< 502 Unknown command received.
* Access denied: 502
* Closing connection #0
curl: (67) Access denied: 502

3. Notice how even though the USER command resulted in a 230 response indicating a successful login, curl sent the PASS command anyway resulting in failure to connect to the ftp server since it does not implement the PASS command.

EXPECTED RESULTS

Prior to the Mac OS X 10.5.8 Security Update 2010-002, the output from step 2 above would be the following instead:

* About to connect() to 172.16.16.85 port 21 (#0)
*   Trying 172.16.16.85... connected
* Connected to 172.16.16.85 (172.16.16.85) port 21 (#0)
< 220 FTP print service:V-1.13/Use the network password for the ID if updating.
> USER anonymous
< 230 User anonymous logged in.
> PWD
< 257 "/" is current directory.
* Entry path is '/'
* Remembering we are in dir ""
* Connection #0 to host 172.16.16.85 left intact
> QUIT
< 221 Good bye.
* Closing connection #0

Notice how with the receipt of the 230 response to the USER command indicating successful login that curl does not send the PASS command.  This is correct.

ACTUAL RESULTS

See Steps to Reproduce section

REGRESSION

This worked properly with Mac OS X 10.5.8 fully patched through security update 2010-001 and broke after installing security update 2010-002.

NOTES

/usr/bin/curl --version reports:

curl 7.16.4 (i386-apple-darwin9.0) libcurl/7.16.4 OpenSSL/0.9.7l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

Replacing /usr/lib/libcurl.4.dylib with the version that was present prior to installing the Mac OS X 10.5.8 Security Update 2010-002 corrects the problem.

Current versions of curl do not suffer from this problem either.

02-Jun-2010 03:32 PM STEVEN ANDRIELLA :
This minor regression affects an extremely small number of users (Leopard-only), and only affects certain ftp servers.  Because resources are currently allocated to other projects affecting larger numbers of users, there is nothing we can do.

We are now closing this bug since our engineers are aware of the issue and will continue to track it offline. A different resolution to this issue may be considered in a future release.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!