Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Tim Hall (thallROOTGROUP.COM)
Date: Wed Jan 17 2001 - 23:50:55 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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


    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

    Reproducing the Vulnerability:

    To reproduce this vulnerability these two conditions must both be

    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, 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.


    Lance Spitzner's original bugtraq post concerning the IP frag attack:


    CheckPoint's official page concerning the previous IP frag attack:


    PhoneBoy's Firewall-1 FAQ site:



    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 <geoffhnrfg.com> for
    his assistance in isolating this problem.

    Tim Hall
    Senior Security Engineer
    The Root Group