FireWall-1, FloodGate-1, VPN-1 Table Saturation Denial of Service Vulnerability
BID:549
Info
FireWall-1, FloodGate-1, VPN-1 Table Saturation Denial of Service Vulnerability
| Bugtraq ID: | 549 |
| Class: | Design Error |
| CVE: | |
| Remote: | Yes |
| Local: | Yes |
| Published: | Jul 29 1999 12:00AM |
| Updated: | Jul 29 1999 12:00AM |
| Credit: | This problem was discovered and documented by Lance Spitzner <[email protected]>. This discovery was posted by Lance to the Bugtraq mailing list on Thu, 29 Jul 1999. Both the discussion and exploit section of this Vulnerability were almost wholly derived |
| Vulnerable: |
Check Point Software Firewall-1 4.0 Check Point Software Firewall-1 3.0 |
| Not Vulnerable: | |
Discussion
FireWall-1, FloodGate-1, VPN-1 Table Saturation Denial of Service Vulnerability
A denial of service condition exists in some implementations of Firewall-1 by Checkpoint Software. This denial of service attack is possible due to the way Firewall-1 handles TCP connections.
Typically to initiate a TCP connection, a SYN packet is sent to the destination host. On systems where Firewall-1 is installed, this packet is first passed through an internal stack maintained by the Firewall before it is passed onto the operating system's native stack. When Firewall-1 filters this packet, it checks it against the rule base. If the session is allowed where it's rulebase is concerned, it is added to the connections table with a timeout of 60 seconds. When the remote host responds with an ACK (Acknowledge) packet, the session is bumped up to a 3600 second timeout.
However, if you initiate a connection with an ACK packet, Firewall-1 compares it against the rule base, if allowed it is added to the connections table. However, the timeout is set to 3600 seconds and does not care if a remote system responds. You now have a session with a 1 hour timeout, even though no system responded. If this is done with a large amount of ACK packets, it will result in a full connections table. This results in your Firewall-1 refusing subsequent connections from any source effectively rendering the Firewall-1 useless in a 'failed closed' state.
A denial of service condition exists in some implementations of Firewall-1 by Checkpoint Software. This denial of service attack is possible due to the way Firewall-1 handles TCP connections.
Typically to initiate a TCP connection, a SYN packet is sent to the destination host. On systems where Firewall-1 is installed, this packet is first passed through an internal stack maintained by the Firewall before it is passed onto the operating system's native stack. When Firewall-1 filters this packet, it checks it against the rule base. If the session is allowed where it's rulebase is concerned, it is added to the connections table with a timeout of 60 seconds. When the remote host responds with an ACK (Acknowledge) packet, the session is bumped up to a 3600 second timeout.
However, if you initiate a connection with an ACK packet, Firewall-1 compares it against the rule base, if allowed it is added to the connections table. However, the timeout is set to 3600 seconds and does not care if a remote system responds. You now have a session with a 1 hour timeout, even though no system responded. If this is done with a large amount of ACK packets, it will result in a full connections table. This results in your Firewall-1 refusing subsequent connections from any source effectively rendering the Firewall-1 useless in a 'failed closed' state.
Exploit / POC
FireWall-1, FloodGate-1, VPN-1 Table Saturation Denial of Service Vulnerability
Most companies allow http outbound. Run this command as root from an internal system, I give your FW about 10 to 15 minutes. If your internal network is a 10.x.x.x, try 172.16.*.*
nmap -sP 10.*.*.*
nmap is a very powerful port scanner. With this command it does only a PING and TCP sweep (default port 80), but uses an ACK instead of a SYN.
To verify that your connections table is quickly growing, try "fw tab -t connections -s" at 10 second intervals.
Tested on ver 4.0 SP3 on Solaris x86 2.6.
Most companies allow http outbound. Run this command as root from an internal system, I give your FW about 10 to 15 minutes. If your internal network is a 10.x.x.x, try 172.16.*.*
nmap -sP 10.*.*.*
nmap is a very powerful port scanner. With this command it does only a PING and TCP sweep (default port 80), but uses an ACK instead of a SYN.
To verify that your connections table is quickly growing, try "fw tab -t connections -s" at 10 second intervals.
Tested on ver 4.0 SP3 on Solaris x86 2.6.
Solution / Fix
FireWall-1, FloodGate-1, VPN-1 Table Saturation Denial of Service Vulnerability
Solution:
Several things you can do to protect yourself:
1. Craft a rule base that reduces ability to insert ACK packets into connections table. For example:
- Minimize ACCEPT rules with destination ANY, one option is to add Client Authentication (with concurrent session limits).
- For those services that use ACCEPT to destination ANY, consider the use of Fast Mode (V4.0) on that service (there are limits on the user of Fast Mode in conjunction with NAT, encryption and other features, please consult the FireWall-1 documentation).
2. I ncrease the size of the connections table, in order to increase the number of ACKs needed to affect connectivity. To do this (assuming V4.0) perform the following:
- Edit $FWDIR/lib/table.def. The attribute limit followed by the limit value (for instance, limit 50000 for 50000 connections), should be inserted after hashsize 8192 attribute of the Connection Table. It must be inserted at the two locations, within $FWDIR/lib/table.def file (the two lines which begin with "connections = ").
Example:
connections = dynamic refresh expires TCP_START_TIMEOUT
expcall KFUNC_EXPIRE implies tracked kbuf 1 hashsize 8192
limit 50000;
- Note that increasing the hashsize value might be needed to maintain performance. hashsize should be a power of 2, and its value should be as approximate number as possible to the limit value. For example, if the limit value is 50,000, hashsize should be 65536.
- Validate that enough memory has been allocated to the Check Point kernel to handle the increased connections table. Using a general rule of: connection table size = ([memory] - X)/60, where X should be a value between 0.5-3 Mbytes (depending on the amount of logging and accounting done by the FireWall), and [memory] is the internal memory allocated for the FireWall-1 (use $FWDIR/bin/fw ctl pstat to get this number). If the connection table size is less then your desired limit, you may need to increase kernel memory. Please see Page 372 in the FireWall-1 4.0 Architecture and Administration User Guide on how to increase the memory allocated to the FireWall-1 kernel (the method is OS dependent).
3. Reduce the default TCP timeout to a low enough value that will be lower than the time it takes to fill the connections table. This has the disadvantage that low activity sessions (e.g., Telnet) may timeout. In case of using NAT hide, this will mean losing the connection.
Check Point has developed INSPECT code changes that provide a solution for this type of attack. This code change enables Check Point gateways to drop non-first TCP packets instead of matching the rule base. It should be noted that this INSPECT fix will cause a change of behavior from the existing Check Point gateway behavior in the following way: following a reboot, policy unload or stopping the firewall, all active TCP connections will be blocked, and that any timed out TCP connections (i.e., connections that have been inactive longer than the TCP timeout) will be disconnected. The ability for FireWall-1/VPN-1 to maintain connections after policy reload will not be affected by this change.
Please note: This solution will cause certain errors, like loss of log information for a few minutes after an fwstart operation.
Please note: This solution is applied to the management station. Once a new policy is reinstalled the problem will be fixed on all the FireWall-1/VPN-1 modules, including any of the embedded ones.
Edit the code.def files as described below.
Check Point 4.0-based Installations
The following INSPECT code (between the two lines starting with "-----") should be added to the $FWDIR/lib/code.def file (at the end of the file, just before the #endif statement). NOTE: if you are managing V3.0 modules, using the 4.0 backwards compatibility feature, please make the changes to the V3.0 code.def file (located in $FWDIR/lib30), as described in the "Check Point 3.0-based Installations". After completing the edit, re-install the security policy. For 4.0-based installations, this code will also log these events.
----- 4.0 edit follows -----
#ifndef ALLOW_NONFIRST_RULEBASE_MATCH
tcp, first or <conn> in old_connections or
(src in firewalled_list, dst in firewalled_list) or
(
#ifndef NO_NONFIRST_RULEBASE_MATCH_LOG
(
<ip_p,src,dst,sport,dport,0> in logged
) or (
record <ip_p,src,dst,sport,dport,0> in logged,
set sr10 12, set sr11 0, set sr12 0, set sr1 0,
log bad_conn
) or 1,
#endif
vanish
);
#endif
----- End of 4.0 insert -----
Check Point 4.1-based Installations
The following INSPECT code (between the two lines starting with "-----") should be edited in the $FWDIR/lib/base.def file (at the end of the file, just before the #endif statement).
----- 4.1 original -----
#ifdef CLUSTER_RULEBASE_MATCH
(call KFUNC_IS_GWCLUSTER<>, tcp, first or in old_connections or
(
----- End of 4.1 original -----
----- 4.1 edit follows -----
#ifdef CLUSTER_RULEBASE_MATCH
(tcp, first or <conn> in old_connections or
(src in firewalled_list, dst in firewalled_list) or
(
----- End of 4.1 edit -----
Check Point 3.0-based Installations:
The following INSPECT code (between the two lines starting with "-----") should be added to the $FWDIR/lib/code.def file (at the end of the file, just before the #endif statement). After completing the edit, re-install the security policy.
----- 3.0 edit follows -----
#ifndef ALLOW_NONFIRST_RULEBASE_MATCH
tcp, first or <conn> in old_connections or vanish;
#endif
----- End of 3.0 insert -----
For more information on FW-1's state connections table, see http://www.enteract.com/~lspitz/fwtable.html
Solution:
Several things you can do to protect yourself:
1. Craft a rule base that reduces ability to insert ACK packets into connections table. For example:
- Minimize ACCEPT rules with destination ANY, one option is to add Client Authentication (with concurrent session limits).
- For those services that use ACCEPT to destination ANY, consider the use of Fast Mode (V4.0) on that service (there are limits on the user of Fast Mode in conjunction with NAT, encryption and other features, please consult the FireWall-1 documentation).
2. I ncrease the size of the connections table, in order to increase the number of ACKs needed to affect connectivity. To do this (assuming V4.0) perform the following:
- Edit $FWDIR/lib/table.def. The attribute limit followed by the limit value (for instance, limit 50000 for 50000 connections), should be inserted after hashsize 8192 attribute of the Connection Table. It must be inserted at the two locations, within $FWDIR/lib/table.def file (the two lines which begin with "connections = ").
Example:
connections = dynamic refresh expires TCP_START_TIMEOUT
expcall KFUNC_EXPIRE implies tracked kbuf 1 hashsize 8192
limit 50000;
- Note that increasing the hashsize value might be needed to maintain performance. hashsize should be a power of 2, and its value should be as approximate number as possible to the limit value. For example, if the limit value is 50,000, hashsize should be 65536.
- Validate that enough memory has been allocated to the Check Point kernel to handle the increased connections table. Using a general rule of: connection table size = ([memory] - X)/60, where X should be a value between 0.5-3 Mbytes (depending on the amount of logging and accounting done by the FireWall), and [memory] is the internal memory allocated for the FireWall-1 (use $FWDIR/bin/fw ctl pstat to get this number). If the connection table size is less then your desired limit, you may need to increase kernel memory. Please see Page 372 in the FireWall-1 4.0 Architecture and Administration User Guide on how to increase the memory allocated to the FireWall-1 kernel (the method is OS dependent).
3. Reduce the default TCP timeout to a low enough value that will be lower than the time it takes to fill the connections table. This has the disadvantage that low activity sessions (e.g., Telnet) may timeout. In case of using NAT hide, this will mean losing the connection.
Check Point has developed INSPECT code changes that provide a solution for this type of attack. This code change enables Check Point gateways to drop non-first TCP packets instead of matching the rule base. It should be noted that this INSPECT fix will cause a change of behavior from the existing Check Point gateway behavior in the following way: following a reboot, policy unload or stopping the firewall, all active TCP connections will be blocked, and that any timed out TCP connections (i.e., connections that have been inactive longer than the TCP timeout) will be disconnected. The ability for FireWall-1/VPN-1 to maintain connections after policy reload will not be affected by this change.
Please note: This solution will cause certain errors, like loss of log information for a few minutes after an fwstart operation.
Please note: This solution is applied to the management station. Once a new policy is reinstalled the problem will be fixed on all the FireWall-1/VPN-1 modules, including any of the embedded ones.
Edit the code.def files as described below.
Check Point 4.0-based Installations
The following INSPECT code (between the two lines starting with "-----") should be added to the $FWDIR/lib/code.def file (at the end of the file, just before the #endif statement). NOTE: if you are managing V3.0 modules, using the 4.0 backwards compatibility feature, please make the changes to the V3.0 code.def file (located in $FWDIR/lib30), as described in the "Check Point 3.0-based Installations". After completing the edit, re-install the security policy. For 4.0-based installations, this code will also log these events.
----- 4.0 edit follows -----
#ifndef ALLOW_NONFIRST_RULEBASE_MATCH
tcp, first or <conn> in old_connections or
(src in firewalled_list, dst in firewalled_list) or
(
#ifndef NO_NONFIRST_RULEBASE_MATCH_LOG
(
<ip_p,src,dst,sport,dport,0> in logged
) or (
record <ip_p,src,dst,sport,dport,0> in logged,
set sr10 12, set sr11 0, set sr12 0, set sr1 0,
log bad_conn
) or 1,
#endif
vanish
);
#endif
----- End of 4.0 insert -----
Check Point 4.1-based Installations
The following INSPECT code (between the two lines starting with "-----") should be edited in the $FWDIR/lib/base.def file (at the end of the file, just before the #endif statement).
----- 4.1 original -----
#ifdef CLUSTER_RULEBASE_MATCH
(call KFUNC_IS_GWCLUSTER<>, tcp, first or in old_connections or
(
----- End of 4.1 original -----
----- 4.1 edit follows -----
#ifdef CLUSTER_RULEBASE_MATCH
(tcp, first or <conn> in old_connections or
(src in firewalled_list, dst in firewalled_list) or
(
----- End of 4.1 edit -----
Check Point 3.0-based Installations:
The following INSPECT code (between the two lines starting with "-----") should be added to the $FWDIR/lib/code.def file (at the end of the file, just before the #endif statement). After completing the edit, re-install the security policy.
----- 3.0 edit follows -----
#ifndef ALLOW_NONFIRST_RULEBASE_MATCH
tcp, first or <conn> in old_connections or vanish;
#endif
----- End of 3.0 insert -----
For more information on FW-1's state connections table, see http://www.enteract.com/~lspitz/fwtable.html