Bugtraq mailing list archives
Re: FireWall-1 FTP Server Vulnerability
From: monti () USHOST COM (monti)
Date: Mon, 14 Feb 2000 19:32:54 -0600
The patch described below does not sound as though it will 'fix the problem'. I could be wrong, but... The enforcement of a newline at the end of the packet might still open the possibility of exploitation through at least one method that I can think of off the top of my head. Possible Example: An FTP server (with at least one writable directory) that allows use of the FTP STAT command. The attacker uploads a file named something along the lines of '227 Entering Passive Mode (xxx,xxx,xxx,xxx,prt,prt)'. The attacker then issues something like a 'stat -1 filename', and plays with her MSS and listing techniques until a proper combination is found and a malicious (and according to description, accepted) packet appears on the wire back through Firewall-1 through the FTP control session. The above has not been tested extensively (namely, not with Firewall-1). I have seen different behavior from various FTP servers. Newer versions of wu-ftpd seem to have already considered this possibility and add a '-' between the '227' and 'Entering' as "227-Entering ...." these suspicious looking files. Others may do this as well. It should be noted also that the 'stat -1' command is only going to work on certain FTP server implementations (most likely unix ones). The -1 is actually being fed to '/bin/ls': (from a telnet to wu-2.4.2-VR17, many others will work) -snip- STAT -1 213-status of -1: . .. 227 Entering Passive Mode (xxx,xxx,xxx,xxx,0,139) bin etc lib pub 213 End of Status STAT --h 213-status of --h: /bin/ls: option `--h' is ambiguous Try `/bin/ls --help' for more information. 213 End of Status -/snip- I presume the '227-Entering' trick on wu-ftpd (and possibly others) would break the above mentioned technique. This isn't of much comfort though, since there are probably countless other ways that an attacker could make the FTP server generate the malicious string and still get it by the new 'enforcement'. FTP implementations vary pretty widely in small details like error strings and the like. I dont really think the issue is with 'how' the PASV response and packet appears on the wire, but with the Firewall's logic in creating a hole for PASV ftp data connections. I think the firewall should probably be a bit more strict about how it makes the decision to open the PASV hole and follow rules like the following: First watch for: client -> ftp-server "PASV" which triggers the firewall to look for this immediately afterwards: client <- ftp-server "227 Entering Passive Mode (xxx,xxx,xxx,xxx,prt,prt) If any other statement is seen from client or server, before the presence of the 227 port declaration, the attempt is ignored. This might still be open to mis-use/tampering, but it would be harder at least (particularly if implemented to enforce strict adherence). Also, some ftp servers might not behave nicely with this... but many of those are probably already broken with firewall-1 anyway? Again, this is largely theoretical. I have not confirmed this to work in the described attack against Firewall-1. If I get some free time, I'll try it. But please consider this for what it's worth for the time-being! Eric Monti Network Security Analyst Denmac Systems 847.291.7760 ericm () denmac com monti () ushost com On Sat, 12 Feb 2000 Lars.Troen () MERKANTILDATA NO wrote:
-----Original Message----- From: Check Point Support [mailto:cpsuppor () ts checkpoint com] Sent: 12. februar 2000 06:01 To: fw-1-mailinglist () lists us checkpoint com Subject: [FW1] Check Point News Announcement News Announcement: http://www.checkpoint.com/techsupport/alerts/pasvftp.html It has been brought to Check Point's attention that a possible vulnerability exists in the control of PASV (passive) FTP connections through FireWall-1. This was developed in a lab environment and requires a specific set of conditions to have existed, in order to suceed. Check Point has no knowledge of its being used against production environments. Summary of vulnerability: FireWall-1's parsing of the FTP control connection was manipulated via MTU such that a FTP server PASV port number, as processed by FireWall-1, was associated with the port number of a service with a known security issue (in this case, ToolTalk port vulnerability on a un-patched Solaris 2.6 system). This enabled the client to exploit the server's vulnerability (i.e., an in.ftpd that returned client-controlled data in an error message and running a possibly unnecessary service: ToolTalk) to gain root access on the machine. This vulnerability was reported to BugTrag on Wednesday, February 9th by John MacDonald of DataProtect. Minimizing the possible threat: - Do not enable PASV FTP if not needed. - Use the FTP Security Server or HTTP security server for PASV FTP connections to internal FTP servers. - Those running publicly accessible FTP servers should follow good host security practices (e.g., not running additional, possibly unnecessary and vulnerable services, keeping up with OS and/or application patches). - For those using stateful inspection of passive FTP, the following patch has been supplied. Patch: The patch consists of a new $FWDIR/lib/base.def file that includes a fix to the problem (the file is compatible with Firewall-1 4.0 SP-5, other platforms will be released as soon as possible). The fix involves an enforcement on the existence of the newline character at the end of each packet on the FTP control connection, this will close off the described vulnerability. It should be noted that this may cause connectivity problems (i.e., blocked FTP connections) in the following scenarios: 1. If FTP control messages larger than the MTU (e.g., large PWD) are exchanged. 2. If some FTP clients/servers does not put newline at the end of the line. 3. When passing FWZ encrypted traffic through an intermediate Firewall gateway. The enforcement can be easily disabled by commenting the following line in the base.def file (or by restoring the original base.def file): #define FTP_ENFORCE_NL Thank you, Check Point Software Technical Services
Current thread:
- Re: FireWall-1 FTP Server Vulnerability Lars.Troen () MERKANTILDATA NO (Feb 12)
- Re: FireWall-1 FTP Server Vulnerability Alexandru Popa (Feb 14)
- Re: FireWall-1 FTP Server Vulnerability monti (Feb 14)
- Re: FireWall-1 FTP Server Vulnerability Henrik Nordstrom (Feb 15)
- DDoS whitepaper Bennett Todd (Feb 17)
- Re: FireWall-1 FTP Server Vulnerability Mikael Olsson (Feb 17)
- Re: FireWall-1 FTP Server Vulnerability Emiliano Kargieman (Feb 18)
- Patch Available for "Site Wizard Input Validation" Vulnerability Microsoft Product Security (Feb 18)
- Re: FireWall-1 FTP Server Vulnerability Dug Song (Feb 18)
- Re: FireWall-1 FTP Server Vulnerability Henrik Nordstrom (Feb 15)
- Re: FireWall-1 FTP Server Vulnerability Borbely Zoltan (Feb 15)
- Re: FireWall-1 FTP Server Vulnerability monti (Feb 17)
- Re: FireWall-1 FTP Server Vulnerability Peter Benie (Feb 16)
- Re: FireWall-1 FTP Server Vulnerability Nick FitzGerald (Feb 17)