IPTables FTP Stateful Inspection Arbitrary Filter Rule Insertion Vulnerability BugTraq ID: 2602 Remote: Yes Date Published: 2001-04-16 Relevant URL: http://www.securityfocus.com/bid/2602 Summary: The Linux kernel includes a built-in firewall implementation called IPTables. IPTables supports stateful inspection of several application protocols, one of which is FTP. The inspection is used to facilitate outgoing PORT connections for FTP data transfers when clients or servers are behind firewalls. Under many firewall configurations and in environments where NAT is in use, PORT mode data transfers normally cannot be used. Some firewalls support stateful inspection of FTP traffic, which can allow the firewall to dynamically open and map ports for FTP data transfers. These firewalls permit the use of PORT mode FTP. In the Linux IPTables implementation, filtering rules for FTP PORT mode data are stored in the table of 'RELATED' connections, temporarily permitting the traffic through the firewall. The IPTables module used to inspect FTP data and interpret PORT requests contains a vulnerability which may allow a remote attacker to insert malicious rules into the firewall's table of related connections. The PORT command accepts two basic parameters, the IP address and TCP port of the destination host. When a PORT command is issued, the server makes a connection to the destination host on that port and transmits the data. To prevent malicious users from utilizing this mechanism to proxy data transfers to arbitrary hosts (ftp bounce attack), most FTP servers compare the destination IP address in the PORT command to the address of the client. If they do not match, the command is rejected and typically logged. The stateful-inspection module also attempts to detect this. When a PORT command containing an IP address which differs from the client's is processed, the occurrence is caught. Despite being detected, the condition is handled erroneously causing an entry for the PORT connection to be inserted into the table of 'RELATED' connections. This temporarily permits traffic through the firewall from the FTP server to the destination included in the PORT command. The following section of source code contains the offending operation in the stateful-inspection module. The 'if' condition below determines whether the IP address in the PORT command matches the client's or not. /* Update the ftp info */ LOCK_BH(&ip_ftp_lock); if (htonl((array[0] << 24) | (array[1] << 16) | (array[2] << 8) | array[3]) == ct->tuplehash[dir].tuple.src.ip) { info->is_ftp = 1; info->seq = ntohl(tcph->seq) + matchoff; info->len = matchlen; info->ftptype = dir; info->port = array[4] << 8 | array[5]; } else { /* Enrico Scholz's passive FTP to partially RNAT'd ftp server: it really wants us to connect to a different IP address. Simply don't record it for NAT. */ DEBUGP("conntrack_ftp: NOT RECORDING: %u,%u,%u,%u != %u.%u.%u.%u\n", array[0], array[1], array[2], array[3], NIPQUAD(ct->tuplehash[dir].tuple.src.ip)); } The problem lies in the 'else' block, which executes if the addresses do not match. After executing, it does not return or otherwise stop the processing of the PORT command. The module continues to function as though the PORT command is valid, creating an entry in the 'RELATED' connections table. Furthermore, clients do not need to authenticate to exploit this vulnerability. Anyone who can reach the service may be able to cause this behaviour, including 'internal' clients. If exploited successfully, an attacker can create a condition where the FTP server can establish connections to arbitrary hosts on any port bypassing IPTables filtering rules. This could be used by an attacker to gain access to internal, protected hosts from the FTP server if it is compromised by an attacker. In addition, an attacker on an internal network could use this vulnerability to access external hosts (which they do not normally have access to) through the FTP server. - Pour poster une annonce: [EMAIL PROTECTED]
