search menu icon-carat-right cmu-wordmark

CERT Coordination Center


State-based firewalls fail to effectively manage session table resource exhaustion

Vulnerability Note VU#539363

Original Release Date: 2002-10-15 | Last Revised: 2003-01-06

Overview

There is a vulnerability in several state-based firewall products that allows arbitrary remote attackers to conduct denial of service attacks against vulnerable firewalls.

Description

Many firewall products use state tables to determine whether a given packet belongs to an existing session between two hosts on opposite sides of the firewall. When the firewall encounters packets that match its rulebase but do not match a currently defined state, a state table entry is added to track the new session. The firewall can remove entries from the state table for several reasons, including expiration of session time-out values and detection of connection teardown packets (such as TCP FIN or TCP RST).

If new entries are added to the state table more rapidly than the firewall is permitted to remove them, the table will eventually fill to capacity. When this occurs, many firewall implementations will refuse to accept incoming packets that do not match an existing session state. In these implementations, no new connections can be established across the firewall, resulting in a denial of service condition. It is important to note that in some firewall implementations, an attacker can fill the session state table with relatively small amounts of traffic, significantly less than the bandwidth capabilities of the firewall's network interface.

There are several methods that attackers can use to exploit this vulnerability:

TCP SYN Flood

To establish a TCP connection, the client and server must participate in a three-way handshake. The client system begins by sending a SYN message to the server. The server then acknowledges the SYN message by sending SYN-ACK message to the client. The client then finishes establishing the connection by responding with an ACK message. The connection between the client and the server is then open, and the service-specific data can be exchanged between the client and the server. Here is a view of this message flow:

Diagram of TCP 3-Way Handshake


In a SYN Flood attack, the attacker sends SYN packets with forged IP source addresses such that the incoming traffic appears to originate from multiple clients. Assuming that the packets match the firewall's rulebase, it will create state table entries to track the pending connections. Because the client addresses are forged, the SYN-ACK messages sent to the clients by the server will be discarded, leaving the firewall's state table filled with bogus entries and eventually creating a denial-of-service condition.

UDP Flood

In a UDP Flood attack, the attacker sends large numbers of small UDP packets with forged IP source addresses. However, because the UDP protocol is connectionless, there are no session status indicators (SYN, SYN-ACK, ACK, FIN, or RST) to assist the firewall in detecting the abnormal protocol states that indicate an attack. As a result, state-based firewalls must rely upon source and destination addresses to create state table entries and set session timeout values.

Crikey CRC Flood

Stephen Gill has discovered a new method of attacking state-based firewalls that he has dubbed the Crikey CRC Flood (C2 Flood). CRC checksums are computed at each network layer (Data Link, Transport, and Network) and are used to detect data corruption caused by transmission errors. A C2 Flood is comprised of packets containing invalid checksums for Transport Layer protocols such as UDP and TCP. Because examination of Transport Layer data is not necessary for firewall operations, many implementers choose to optimize performance by ignoring these checksums. Therefore, if an incoming C2 Flood packet matches the firewall's rulebase, it will create a session table entry and pass the invalid packet to the destination host.

Unlike the firewall, the destination host must verify all checksums to prevent itself from accepting corrupted packets. In accordance with common networking convention, most hosts that receive invalid packets from a C2 Flood will simply discard them, assuming that failure to respond will cause the source host to retransmit the data. This presents a problem for the firewall because, under these conditions, the destination host will not provide feedback that the firewall can use to adjust its state table.

Impact

Arbitrary remote attackers can conduct denial of service attacks against vulnerable firewalls.

Solution

Follow the recommendations of your vendor


Please see the vendor information section of this document for a list of vendor-specific recommendations for addressing this vulnerability.

The attacks described in this document are difficult to block completely, but there are several improvements that developers can make to reduce their impacts. Several of these techniques are described below:


Use firewall features that detect and block flood traffic

Many firewalls provide features that can detect and block UDP and TCP SYN floods. The CERT/CC recommends that site administrators make use of these features whenever possible.

Use dynamically resizeable state tables

State tables that use dynamically allocated storage can expand to accommodate large numbers of states. This will increase the difficulty of exploiting this vulnerability, but it is important to note that the size of a dynamic state table will still be bounded by a firewall's available memory.

Use separate timeout values for initial sessions

Maintaining separate session timers for initial and established sessions allows state table entries generated by attack traffic to be rapidly removed while still permitting legitimate entries to remain in the state table. Since most attacks rely upon forged IP source addresses from which no reply is expected, attack traffic is unlikely to create state table entries that appear to be established sessions.

Use dynamically adjustable session timers (Aggressive Aging)

As the session time out value decreases, the attacker must increase the traffic rate to ensure that new entries are created faster than the firewall is permitted to remove them. By using dynamic session timers that decrease in response to state table congestion, the firewall can increase its rate of session expiration, making this vulnerability more difficult to exploit.

Allow connection tracking to be disabled

The ability to disable connection tracking for certain protocols would provide administrators with increased flexibility in defending against the attacks described above.

Vendor Information

539363
Expand all

Alcatel

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Vulnerable

Vendor Statement

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.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Check Point

Notified:  June 05, 2002 Updated:  October 31, 2002

Status

  Vulnerable

Vendor Statement

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.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Cisco Systems Inc.

Notified:  June 05, 2002 Updated:  October 31, 2002

Status

  Vulnerable

Vendor Statement

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 <num> block <minutes>

The IOS FW in the latest versions of code dynamically allocates memory for session state tables.

The IOS FW uses separate timeout values for initial sessions -
- half-open sessions have an idle timeout of 30 seconds.
- full-open TCP sessions have an idle timeout of 3600 seconds.
- full-open UDP sessions have an idle timeout of 30 seconds.
- DNS UDP sessions are treated specially and have an idle timeout of 5 seconds instead of 30 seconds.
- TCP sessions have a fin-wait timeout of 5 seconds for closing sessions.
- half-open and full-open idle timeouts can be configured to different values.

Full-open sessions can have configurable timeouts based on each supported application, e.g. FTP full-open idle timeout can be configured differently from SMTP full-open idle timeout.

The IOS FW allows for individually configuring supported protocol's which need their connections tracked. One can choose to turn on or turn off tracking for any supported protocol.

The IOS FW has a feature in the works which would allow one to delete selected or all sessions in the state table with a CLI command.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

IBM

Notified:  June 05, 2002 Updated:  October 23, 2002

Status

  Vulnerable

Vendor Statement

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

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NetScreen

Notified:  June 05, 2002 Updated:  November 27, 2002

Status

  Vulnerable

Vendor Statement

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.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Netscreen has published NetScreen Security Alert 52020 to address this issue; for more information, please see

Apple Computer Inc.

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Not Vulnerable

Vendor Statement

Mac OS X and Mac OS X Server do not contain the vulnerability described in this report.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Cray Inc.

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Not Vulnerable

Vendor Statement

Cray, Inc. is not vulnerable as we provide no software that performs this type of function.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Fujitsu

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Not Vulnerable

Vendor Statement

Fujitsu's UXP/V operating system is not affected by the bug reported in VU#539363. UXP/V does not support state-based firewalls.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Microsoft Corporation

Notified:  June 05, 2002 Updated:  October 15, 2002

Status

  Not Vulnerable

Vendor Statement

Microsoft ISA Server 2000 is not affected by the attacks described in the research paper.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NetBSD

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Not Vulnerable

Vendor Statement

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.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Nortel Networks

Notified:  June 05, 2002 Updated:  November 27, 2002

Status

  Not Vulnerable

Vendor Statement

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.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

This statement was submitted to the CERT/CC on Tuesday, November 5, 2002.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenBSD

Notified:  June 05, 2002 Updated:  October 23, 2002

Status

  Not Vulnerable

Vendor Statement

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.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

3Com

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

AT&T

Notified:  September 25, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

BSDI

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Compaq Computer Corporation

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Conectiva

Notified:  September 25, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Data General

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Debian

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

F5 Networks

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

FreeBSD

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Guardian Digital Inc.

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Hewlett-Packard Company

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Intel

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Intoto

Notified:  October 24, 2002 Updated:  October 31, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Juniper Networks

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Lachman

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Lucent

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

MandrakeSoft

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

MontaVista Software

Notified:  September 25, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Multinet

Notified:  September 25, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NEC Corporation

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Network Appliance

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Openwall GNU/*/Linux

Notified:  September 25, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Red Hat Inc.

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SGI

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sequent

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sony Corporation

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SuSE Inc.

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sun Microsystems Inc.

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

The SCO Group (SCO Linux)

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

The SCO Group (SCO UnixWare)

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Unisphere Networks

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Unisys

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Wind River Systems Inc.

Notified:  June 05, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Wirex

Notified:  September 25, 2002 Updated:  October 11, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A

References

Credit

The CERT/CC thanks Stephen Gill for his discovery and analysis of this vulnerability.

This document was written by Jeffrey P. Lanza.

Other Information

CVE IDs: None
Severity Metric: 19.69
Date Public: 2002-10-15
Date First Published: 2002-10-15
Date Last Updated: 2003-01-06 21:50 UTC
Document Revision: 120

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.