[ SOURCE: http://www.secureroot.com/security/advisories/9798443762.html ] I have identified a denial of service attack that can be launched against Firewall-1 that has identical results to the IP fragmentation attack identified by Lance Spitzner. Symptoms: Firewall CPU hits 100% utilization, console locks up, a reboot only temporarily solves the problem. Vulnerable: All versions of Firewall-1 4.1 on Solaris 2.x using a limited-IP license Probably Vulnerable: All versions of Firewall-1 4.1 using a limited-IP license on Nokia IPSO, possibly other variants of Unix Not vulnerable: Firewall-1 4.0 (all service packs) and earlier Discussion: On firewall modules with a limited-IP license, Firewall-1 counts the number of unique source IP addresses entering all non-outside interfaces. The outside interface typically is Internet-facing. If more IP addresses are counted that the firewall module is licensed for, a warning message is output to the firewall's console. In 4.1, the warning includes a list of all IP addresses counted in the Firewall-1 licensing calculation. The 4.0 message only included the number of IP addresses corresponding to the licensed limit. By sending a large number of packets with spoofed source addresses to any inside interface, enough addresses will be included in the console output to cause a new warning message to be issued before the previous one can finish. As a result the console device will be overrun and begin to consume large amounts of CPU time. This output makes the console virtually unusable making it more difficult to recover from this situation. There is no way to block this behavior in the rule base. Even if the spoofed packets in question are dropped explicitly by a rule or implicitly by antipspoofing they will still be included in the license calculation. A reboot will not clear this problem either, since Firewall-1 will begin sending the license violation messages to the console immediately upon rebooting. Clearing the license count as described at PhoneBoy's site will help temporarily, but if the flood of spoofed packets continues Firewall-1 will rapidly end up in the same state again. Reproducing the Vulnerability: To reproduce this vulnerability these two conditions must both be true: 1) The firewall module has to have a limited-IP license 2) An attacker has to be able to route packets to any inside interface of the firewall. Note that this could include DMZ interfaces as well as the "inside" network; only the single defined outside interface is impervious. Also note that the packets do not have to be accepted by the firewall's security policy. Any tool that can send a stream of packets with random, unique source IP addresses can be used to reproduce this problem. The SYN flooder synk4.c is an excellent example. In our testing we found that once the firewall module was attempting to output approximately 6,000 IP addresses to the console it would be overrun. On a high-speed LAN a SYN flooder could send this amount of traffic in seconds. Work Around/Fix: Similar to the IP Frag attack, issuing a 'fw ctl debug -buf' will prevent this console logging from consuming excessive CPU. While many firewall administrators installed this workaround earlier to combat the frag problem, it was probably removed from the fwstart script when they upgraded to SP2 or later. Vendor Reporting: I contacted CheckPoint immediately after discovering this problem. They have confirmed that it is indeed a problem and recommend using the 'fw ctl debug -buf' workaround as an immediate solution. CheckPoint is currently researching a more permanent solution to the problem and will include the solution in a further release. Initial Discovery: I was called into a client site whose High Availability Firewall cluster was hanging and crashing constantly. A closer examination of the firewalls revealed that they were 100% utilized spewing license warnings onto the console port which was overwhelmed with data. A "fw lichosts" revealed thousands of bogus addresses being counted in the license calculation and thus pushing the customer over their license. These bogus addresses were things like 254.3.4.5, 0.0.3.4 and so on; the external interface was defined properly so that wasn't the problem. It turned out that a Cisco LocalDirector was spewing packets with garbage source and destination IP addresses on a DMZ interface. This is a known Cisco bug and has Cisco bugID #CSCdr08284. Then it occurred to me than one could induce this situation by flooding the firewall with IP datagrams carrying random source IP addresses. Firewall-1 would be so busy spewing license warnings to the console nothing else would get done. References: Lance Spitzner's original bugtraq post concerning the IP frag attack: http://www.securityfocus.com/archive/1/63478 CheckPoint's official page concerning the previous IP frag attack: http://www.checkpoint.com/techsupport/alerts/ipfrag_dos.html PhoneBoy's Firewall-1 FAQ site: http://www.phoneboy.com/fw1 Thanks: I'd like to thank Scott Walker Register of CheckPoint for his prompt and courteous assistance in dealing with this matter. I'd also like to thank Geoff Hannam for his assistance in isolating this problem. Tim Hall Senior Security Engineer The Root Group thall@rootgroup.com http://www.rootgroup.com