Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Affected
In relation to this note on security vulnerabilities in various state-based firewall implementations, it is first important to realize that the attacks mentioned in this note cannot be fully countered but appropriate and sound engineering designs can mitigate them. Alcatel has taken such appropriate measures to ensure that our products, in particular the OmniAccess 200 series, are correctly designed. Customers may contact their Alcatel support representative for more details. The security of our customers' networks is of highest priority for Alcatel. Therefore we continue to test our product portfolio against these potential security vulnerabilities in our products and will provide updates if necessary.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Not Affected
Mac OS X and Mac OS X Server do not contain the vulnerability described in this report.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: September 25, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 31, 2002
Affected
CERT VU#539363 describes various mechanisms which could be used to exhaust the session tables on state-based firewalls, thereby blocking legitimate connections. Current Check Point VPN-1/FireWall-1 products offer excellent protection against session table exhaustion, and are not vulnerable to the special attack variants described in this vulnerability note. Special enhancements have been added to Feature Pack 3, and within SmartDefense, to assist Check Point’s customers in dealing with such issues. Check Point recommends that security products be kept up to date, for the highest levels of security and performance. TCP SYN Flood: Check Point offers SYNdefender as an integral feature of FireWall-1. This feature has been substantially enhanced in Check Point’s SmartDefense product, which offers automatic passive/active switching for the highest level of security without performance compromise. UDP Flood: A properly configured firewall rulebase will allow very few inbound UDP connections with no restrictions on source IP addresses. In most deployments, only DNS queries would be allowed into a network in this manner (and then only if an organization is hosting its own DNS server). Check Point’s DNS validation code will ensure that inbound packets are, in fact, valid DNS queries. In addition, UDP timeouts in VPN-1/FireWall-1 NG FP3 have been lowered (and are configurable) for added protection. VPN-1/FireWall-1 NG FP3 has an additional feature to deal with non-TCP Floods: Session Table Allocation, which allows the administrator to reserve a certain number of connection table entries for TCP connections, which are more likely to be used for mission-critical traffic (such as web and email). Even if a flood of UDP (or any other non-TCP) packets "succeeds" in using up many connection table slots, this will not reduce the number of TCP sessions the administrator has reserved - email, ftp, and web traffic would be unaffected by a non-TCP Flood. Crikey CRC Flood: This type of attack has no special impact on VPN-1/FireWall-1. An incoming TCP or UDP packet with an invalid CRC must be one of the following: 1) a TCP SYN packet, which is handled by Check Point’s standard SYN flood protection 2) a non-SYN TCP packet, which will be discarded by the firewall since it does not match an existing connection 3) a UDP packet, which is handled by Check Point’s standard UDP protection It is important to note that Check Point does not create a session table entry simply because it receives a non-SYN packet which matches the rule base.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 31, 2002
Affected
The Cisco PIX and Cisco IOS firewall provides users with many configurable features to effectively manage the session tables and are not vulnerable to resource exhaustion when configured appropriately. PIX specific information: The PIX provides the ability to defend against a TCP flood attack by using the TCP Intercept feature which leverages SYN Cookies. The PIX SYN Cookie implementation is stateless and does not need to maintain states when responding to a TCP SYN flood and thus does not require having a more aggressive timeout. This enhanced TCP intercept functionality is available in all of the latest PIX maintenance releases: 6.2(2), 6.1(4),6.0(4) and 5.2(9) The PIX is not vulnerable to an ACK attack as it requires a SYN to initiate a session. The PIX has the Reverse-Path-Forwarding feature which ensures that the source IP addresses presented to the PIX have reached the PIX from a legitimate interface and thus are not spoofed. The PIX has configurable timeout values for UDP traffic and also for specific UDP protocols like SIP, RPC, RTP, etc. The security features available on the PIX to guard against a SYN flood or a UDP flood also address the Crikey CRC flood. The PIX TCP Intercept feature will prevent the Crikey CRC flood packets from reaching the server in the same way it protects against the TCP SYN flood. One should always use Access Lists to limit the traffic to only allow valid traffic to reach one's network. IOS FW specific information: TCP SYN flood protection
- half-open sessions time out in 30 seconds (default). Can be configured to a smaller value or higher value
- configurable limit on maximum number of half-open sessions at a given time
- full-open sessions time out in 3600 seconds (default) Can be configured to a smaller value or higher value UDP flood protection
- one way UDP is considered to be a half-open session
- half-open sessions time out in 30 seconds (default). Can be configured to a smaller value or higher value
- configurable limit on maximum number of half-open sessions at a given time
- all UDP sessions time out after 30 second of inactivity including full-open sessions. Can be configured to a smaller value or higher value Crikey flood protection
- No special protection (IOS FW does not validate checksum)
- If the Layer 4 checksum in wrong in a SYN packet, or the initial UDP packet then the session will remain half-open and the above described mechanisms will take effect. The IOS FW has features to detect and block flood traffic that are automatically turned on, with appropriate default values, when the IOS FW is activated. IOS FW CLI cmds to configure these features are: - ip inspect max-incomplete high/low
- ip inspect one-minute high/low
- ip inspect tcp max-incomplete
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: September 25, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Not Affected
Cray, Inc. is not vulnerable as we provide no software that performs this type of function.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Not Affected
Fujitsu's UXP/V operating system is not affected by the bug reported in VU#539363. UXP/V does not support state-based firewalls.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 23, 2002
Affected
IBM Tivoli Firewall is not generally vulnerable to Denial of Service (DOS) attacks by session table filling. IBM firewall is not a full fledged stateful packet filter, but more like a Stateful-Inspection with Connection-Centric deterministic-filtering firewall. When a connection is requested for dynamic PASV ftp traffic or RealAudio traffic, this connection must first meet connection filter requirements, then build an FBE (Function Block Entry) to maintain session state if the connection meets endpoint and protocol filter requirements. Vulnerability to the session table filling hack only exists in a limited way on the IBM Tivoli Firewall and only on tables maintained for these policies (PASV FTP and RealAudio). If this hack somehow gets past the filters in place that should specify endpoints, AND the tables are filled somehow, then and only then will the PASV ftp and RealAudio traffic will be impacted (and this impact is limited to slowdown or stop, NOT security); all other functions of the IBM Tivoli Firewall will continue to perform as before. Another connection type that grows a table based on connections is NAT dynamic map table when NAT is active. This table maintains dynamic list of many-to-one entries for each connection going from secure to non-secure network. The attack on this table can only occur with traffic from secure to non-secure network; and, since each connection must be maintained to fill the table, it is easy to identify source of attack since it is listed, allowed by rule, and must be maintained during the period of the attack (not to mention the fact that it originates on the secure side of the Firewall and must be explicitly configured by endpoints before connection requests will even enter the table).
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: October 24, 2002 Updated: October 31, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 15, 2002
Not Affected
Microsoft ISA Server 2000 is not affected by the attacks described in the research paper.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: September 25, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: September 25, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Not Affected
TCP SYN Flood IPFilter is not vulnerable to this attack as it already implements aggressive flushing of the state table when it detects it to be full. UDP Flood There is no specific attack here that IPFilter needs to defend against. It will time things out according to timeouts set for UDP (can be done on a per-rule basis.) Crikey CRC Flood IPFilter does not currently allow packets to be rejected because of bad CRC's but the problem posed here is dealt with in the two aforementioned briefs. Solutions IPFilter supports the use of separate timeout values for initial sessions and allows connection tracking to be disabled.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: November 27, 2002
Affected
NetScreen has studied the issues raised in this vulnerability alert. With proper configuration of their firewalls, customers can virtually eliminate the impact of any of the proposed DoS attacks. Specifically, customers are strongly advised to utilize NetScreen's SYN Flood protection and UDP rate limiter. On some platforms, default timeout parameters might need to be changed in order to have a more consistent response to these attacks. Please refer to NetScreen's support site for more information.
The vendor has not provided us with any further information regarding this vulnerability.
Netscreen has published NetScreen Security Alert 52020 to address this issue; for more information, please see http://www.netscreen.com/support/alerts/Potential_H_323_Denial_of_Service.html
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: November 27, 2002
Not Affected
The following Nortel Networks products use state-based firewall technology: The Alteon Switched Firewall incorporates FireWall-1 technology licensed from Check Point Software Technologies, Inc. Please refer to the Vendor Statement posted by Check Point Software Technologies, Inc. There are no issues with the Contivity Platform, this includes the: Contivity 600/1500/1600/2000/2500/2600/4500/4600 Contivity 1010/1050/1100 Contivity 1700/2700 Contivity software releases 3.5 and beyond including the CVC Client The Shasta 5000 Broadband Services Node is not affected.
The vendor has not provided us with any further information regarding this vulnerability.
This statement was submitted to the CERT/CC on Tuesday, November 5, 2002.
Notified: June 05, 2002 Updated: October 23, 2002
Not Affected
The stateful packet filter (pf) that ships with OpenBSD 3.0 and later offers several configuration options to deal with this kind of attack. State table entries are allocated from a dedicated kernel memory pool. A hard limit for maximum number of state entries can be configured. When this limit is reached, further packets that require state entry creation are dropped, until existing state entries time out. Other memory pools are not affected. Each filter rule that creates state entries for matching packets can specify an individual maximum number of states created by it. When one rule has reached its own maximum, other rules can still create new state entries, up to their own maxima (or the global hard limit). The state timeout values (period of time of inactivity after which a state entry is removed) for each phase of a connection can be can be configured globally, per protocol and in each rule that creates state entries. Low timeouts can be used to purge individual connections early. Aggressive timeouts for TCP connections that are not fully established force an attacker to complete the TCP handshake to create long-lived state entries, addressing spoofed SYN floods. With a balanced choice of maxima and timeouts, and depending on the available amount of memory and the highest possible packet rate, the state table does not reach its size limits.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: September 25, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: June 05, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: September 25, 2002 Updated: October 11, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.