Check Point Firewall-1 Unauthorized RSH/REXEC Connection Vulnerability
BID:1534
Info
Check Point Firewall-1 Unauthorized RSH/REXEC Connection Vulnerability
| Bugtraq ID: | 1534 |
| Class: | Input Validation Error |
| CVE: | |
| Remote: | Yes |
| Local: | No |
| Published: | Aug 02 2000 12:00AM |
| Updated: | Aug 02 2000 12:00AM |
| Credit: | The following individuals discovered this vulnerability and discussed it at Black Hat 2000. Thomas Lopatic and John McDonald, TUV data protect GmbH Dug Song, University of Michigan CITI |
| Vulnerable: |
Check Point Software Firewall-1 4.1 Check Point Software Firewall-1 4.0 Check Point Software Firewall-1 3.0 |
| Not Vulnerable: | |
Discussion
Check Point Firewall-1 Unauthorized RSH/REXEC Connection Vulnerability
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.
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.
Exploit / POC
Check Point Firewall-1 Unauthorized RSH/REXEC Connection Vulnerability
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected].
Solution / Fix
Check Point Firewall-1 Unauthorized RSH/REXEC Connection Vulnerability
Solution:
Check Point Software has released service packs that deal with this vulnerability.
For VPN-1/FireWall-1 4.0: Apply the latest Service Pack for your system (SP7 or later).
For VPN-1\FireWall-1 4.1: Apply the latest Service Pack for your system (SP2 or later).
Check Point Software Firewall-1 4.0
Check Point Software Firewall-1 4.1
Solution:
Check Point Software has released service packs that deal with this vulnerability.
For VPN-1/FireWall-1 4.0: Apply the latest Service Pack for your system (SP7 or later).
For VPN-1\FireWall-1 4.1: Apply the latest Service Pack for your system (SP2 or later).
Check Point Software Firewall-1 4.0
-
Check Point Software Service Packs
http://www.checkpoint.com/techsupport/index.html
Check Point Software Firewall-1 4.1
-
Check Point Software Service Packs
http://www.checkpoint.com/techsupport/index.html
References
Check Point Firewall-1 Unauthorized RSH/REXEC Connection Vulnerability
References:
References:
- A Stateful Inspection of Firewall 1 - Slides from BlackHat 2000 Presentation (Dug Song, Thomas Lopatic, John McDonald)
- Potential Security Issues Recently Identified in FireWall-1 (Check Point Software)