Check Point Firewall-1 is vulnerable to certain unauthorized connections, caused by sending a specially formatted RSH/REXEC connection request from an external RSH/REXEC server to an internal (protected) RSH/REXEC client. This can only be done if the FireWall-1 administrator specifically enabled RSH/REXEC with stderr-port support in the Properties window. The problem has to do with the pending table used to store state information for when rsh connections are initialized with stderr-port support. The pending table is a Firewall-1 internal memory structure used to hold temporary information about the state of a new connection before it is added to the "connection table", where state information (remote, destination ip addresses and ports, protocol type, etc) for permitted connections is stored. Because of the way data from the pending table is interpreted and certain conditions met by the nature of Firewall-1's handling of the rsh/rexec stderr-port (the acceptance of an additional...
Check Point Firewall-1 is vulnerable to certain unauthorized connections, caused by sending a specially formatted RSH/REXEC connection request from an external RSH/REXEC server to an internal (protected) RSH/REXEC client. This can only be done if the FireWall-1 administrator specifically enabled RSH/REXEC with stderr-port support in the Properties window. The problem has to do with the pending table used to store state information for when rsh connections are initialized with stderr-port support. The pending table is a Firewall-1 internal memory structure used to hold temporary information about the state of a new connection before it is added to the "connection table", where state information (remote, destination ip addresses and ports, protocol type, etc) for permitted connections is stored. Because of the way data from the pending table is interpreted and certain conditions met by the nature of Firewall-1's handling of the rsh/rexec stderr-port (the acceptance of an additional syn packet), it is possible to collide an entry in the pending table before it is written to the connection table as the stderr-port connection. When stderr connections for rsh/rexec are permitted, information from the first data packet of an rsh connection is stored in the pending table so the firewall can anticipate the stderr syn. The stderr port is extracted from the tcp data segment of this initial data packet. In addition, the source, destination ip addresses and ports are stored, as well as a magic number and the IP protocol code. Firewall-1 then waits for a syn for the stderr connection. When one is recieved, another entry is made into the pending table, only the sequence number + 1 is stored in the place where the IP protocol number would go. If a malicious SYN is crafted with a sequence number of 5 and sent to the Firewall-1 that is expecting a rsh/rexec stderr syn, the sequence number will be stored as 6 in the place where the protocol code (which happened to be 6, for TCP) is for the previous entry. The firewall then checks this and allows this connection to be established regardless of what the port is in the malicious syn. It is then possible for an attacker to communicate with an "rsh client' on an arbitrary port behind the firewall. The impact is that if rsh/rexec stderr-port is permitted, back-connections through the firewall can be established.
