CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 6 of 6

Thread: Panic When SecureXL and NAT Are Used and a Malformed Packet Is Received

  1. #1
    Join Date
    2005-08-14
    Location
    Gig Harbor, WA, USA
    Posts
    2,494
    Rep Power
    17

    Default Panic When SecureXL and NAT Are Used and a Malformed Packet Is Received

    I'm putting on my Nokia hat here for a moment to ensure you are all aware of a critical security vulnerability that has been announced against Nokia IPSO. I'll answer whatever questions I can about this.

    -- PhoneBoy

    P.S. This notice was updated as noted below.

    -- snip --

    Panic When SecureXL and NAT Are Used and a Malformed TCP Packet is Received

    Revision 1, February 4, 2009

    Summary

    Nokia security appliances running Nokia IPSO 4.1, 4.2, 5.0, 6.0 or older can panic if SecureXL and NAT are enabled and certain malformed
    TCP packets are sent in an attempt to attack the network. Note: IPSO 6.1 is not vulnerable to this issue.

    Risk Analysis

    To exploit this vulnerability, the Nokia appliance must be configured with both SecureXL and NAT enabled; the attacker must be able to send malformed TCP packets to the firewall and firewall policy must be set to allow these malformed packets.

    Severity: High

    Population Affected

    Any Nokia security appliance running with SecureXL and NAT enabled when specific malformed TCP packets are sent through the firewall.

    1. Customer Recommended Actions

    Customers who are not running SecureXL and NAT need not take action as their systems are not vulnerable. All other customers are recommended to either upgrade Nokia IPSO or enhance their firewall policy to drop these packets.

    More information about these fixes and workarounds are available in Nokia knowledgebase article KB1357601, which will be updated as new information becomes available.

    Best practices documented in RFC1858 suggest that forwarding packets smaller than 68 bytes may open your network to "Tiny Fragment Attacks." The various workarounds discussed below place restrictions on what kinds of fragmented packets are allowed to be forwarded.

    2. Recommended IPSO Changes

    If choosing to upgrade Nokia IPSO, the following versions are available via the Nokia Knowledge Base:

    1. IPSO 4.2 build 096 or later
    2. IPSO 4.1 build 053 or later
    3. IPSO 5.0 build 056 for VSX NGX R65 or later (Nokia knowledge base article KB1611013 – this is a controlled access article, please contact Nokia Technical Support for further information)

    Customers using IPSO 6.0 should upgrade to IPSO 6.1.

    3. Alternative Check Point Policy Changes

    As an alternative to upgrading Nokia IPSO or VSX, the Check Point VPN-1/FireWall-1 application can be enhanced to drop these packets on a policy level before they are passed to the IPSO kernel thereby preventing the issue. To accomplish this, one of the following configuration changes should be made to the firewall:

    Enable Smart Defense option Forbid IP Fragments. This option may result in connectivity issues if other desired but fragmented traffic exists.

    Using GUIDBEDIT set fwfrag_minsize to 20. This option may result in connectivity issues if other desired but fragmented UDP traffic exists. More details this workaround are available in Nokia knowledgebase article KB1357601.

    Disable SecureXL. This option may result in an unacceptable level of performance degradation.

    Acknowledgements

    Nokia gratefully acknowledges Karthik Chandrashekar, Damon LeRoy and Kevin Sahota of eBay Network Security for their work leading to the discovery and responsible disclosure of this issue.
    Last edited by PhoneBoy; 2009-02-06 at 04:27.

  2. #2
    Join Date
    2008-10-06
    Posts
    10
    Rep Power
    0

    Default Re: Panic When SecureXL and NAT Are Used and a Malformed Packet Is Received

    Just want to confirm...fwfrag_minsize is IP payload bytes right? Is there still an issue if this is set to 8 so no *valid* udp traffic will get dropped either?

    Cheers,
    B-)

  3. #3
    Join Date
    2005-08-14
    Location
    Gig Harbor, WA, USA
    Posts
    2,494
    Rep Power
    17

    Default Re: Panic When SecureXL and NAT Are Used and a Malformed Packet Is Received

    I believe it is IP payload, though I am checking.

  4. #4
    Join Date
    2005-08-14
    Location
    Gig Harbor, WA, USA
    Posts
    2,494
    Rep Power
    17

    Default Re: Panic When SecureXL and NAT Are Used and a Malformed Packet Is Received

    The value is number of bytes after the IP header. fwfrag_minsize needs to be 20 to ensure that a complete TCP header is received. This does mean that legitimate UDP fragments with less than 12 data bytes will be dropped if you apply this fix.

  5. #5
    Join Date
    2007-02-27
    Posts
    83
    Rep Power
    14

    Default Re: Panic When SecureXL and NAT Are Used and a Malformed Packet Is Received

    I am working on a high profile case where the customer is running IP2250, IPSO 4.2 build 096 + R65 HFA04 where the IPSO is panicking with adp errors.

    We have to switch off SecureXL to stabilise the environment. Currently with CP engineering to analyse the core files.

  6. #6
    Join Date
    2010-03-23
    Posts
    102
    Rep Power
    11

    Default Re: Panic When SecureXL and NAT Are Used and a Malformed Packet Is Received

    Quote Originally Posted by th0i3 View Post
    I am working on a high profile case where the customer is running IP2250, IPSO 4.2 build 096 + R65 HFA04 where the IPSO is panicking with adp errors.

    We have to switch off SecureXL to stabilise the environment. Currently with CP engineering to analyse the core files.
    This isn't related to what PhoneBoy posted. There are at *least* two ADP issues I know of in build 096, as well as there being another known SecureXL issue that is resolved in build 105.

    I've got a special kana perf_g file that resolves one issue, and a special build of IPSO that resolves the other ADP issue...fun times.
    CCMSE+VSX, CCSE+, CCMA

Similar Threads

  1. SecureXL problem: TCP packet out of state: First packet isnīt SYN tcp_flags: PUSH-ACK
    By mhernandez in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 4
    Last Post: 2014-09-18, 05:37
  2. Malformed Packet & UDP length error
    By Raj909 in forum IPS Blade (Formerly SmartDefense)
    Replies: 8
    Last Post: 2009-11-02, 13:23
  3. Received notification: payload malformed after building HA Cluster
    By in0d3 in forum SecureClient/SecuRemote
    Replies: 5
    Last Post: 2009-03-03, 17:54
  4. received HAP packet with bad magic number fb58
    By masif in forum Miscellaneous
    Replies: 0
    Last Post: 2007-04-05, 09:20
  5. SSLv3: Malformed Packet (field lengths do not match)
    By switzer in forum IPS Blade (Formerly SmartDefense)
    Replies: 1
    Last Post: 2006-12-21, 08:17

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •