CVE Vulnerabilities

CVE-2006-0340

Improper Input Validation

Published: Jan 21, 2006 | Modified: Jul 20, 2017
CVSS 3.x
N/A
Source:
NVD
CVSS 2.x
7.1 HIGH
AV:N/AC:M/Au:N/C:N/I:N/A:C
RedHat/V2
RedHat/V3
Ubuntu

Unspecified vulnerability in Stack Group Bidding Protocol (SGBP) support in Cisco IOS 12.0 through 12.4 running on various Cisco products, when SGBP is enabled, allows remote attackers on the local network to cause a denial of service (device hang and network traffic loss) via a crafted UDP packet to port 9900.

Weakness

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

Affected Software

Name Vendor Start Version End Version
Ios Cisco 12.3ym 12.3ym
Ios Cisco 12.0xc 12.0xc
Ios Cisco 12.3yq 12.3yq
Ios Cisco 12.0xk 12.0xk
Ios Cisco 12.4t 12.4t
Ios Cisco 12.0xr 12.0xr
Ios Cisco 12.1xm 12.1xm
Ios Cisco 12.1xi 12.1xi
Ios Cisco 12.3bc 12.3bc
Ios Cisco 12.1e 12.1e
Ios Cisco 12.1ya 12.1ya
Ios Cisco 12.1yd 12.1yd
Ios Cisco 12.2zn 12.2zn
Ios Cisco 12.1xs 12.1xs
Ios Cisco 12.0xe 12.0xe
Ios Cisco 12.3bw 12.3bw
Ios Cisco 12.1xy 12.1xy
Ios Cisco 12.3xd 12.3xd
Ios Cisco 12.3xm 12.3xm
Ios Cisco 12.0xd 12.0xd
Ios Cisco 12.3xw 12.3xw
Ios Cisco 12.4mr 12.4mr
Ios Cisco 12.2su 12.2su
Ios Cisco 12.1xz 12.1xz
Ios Cisco 12.2xg 12.2xg
Ios Cisco 12.0xj 12.0xj
Ios Cisco 12.2b 12.2b
Ios Cisco 12.1t 12.1t
Ios Cisco 12.3xi 12.3xi
Ios Cisco 12.2yn 12.2yn
Ios Cisco 12.3yj 12.3yj
Ios Cisco 12.2xb 12.2xb
Ios Cisco 12.2xl 12.2xl
Ios Cisco 12.2yw 12.2yw
Ios Cisco 12.3yu 12.3yu
Ios Cisco 12.2yd 12.2yd
Ios Cisco 12.3xj 12.3xj
Ios Cisco 12.0xl 12.0xl
Ios Cisco 12.3t 12.3t
Ios Cisco 12.3 12.3
Ios Cisco 12.2dd 12.2dd
Ios Cisco 12.1ga 12.1ga
Ios Cisco 12.1xl 12.1xl
Ios Cisco 12.2t 12.2t
Ios Cisco 12.2yt 12.2yt
Ios Cisco 12.0xh 12.0xh
Ios Cisco 12.0t 12.0t
Ios Cisco 12.1xw 12.1xw
Ios Cisco 12.2za 12.2za
Ios Cisco 12.2ye 12.2ye
Ios Cisco 12.1yb 12.1yb
Ios Cisco 12.2zb 12.2zb
Ios Cisco 12.1gb 12.1gb
Ios Cisco 12.1ex 12.1ex
Ios Cisco 12.3xf 12.3xf
Ios Cisco 12.1 12.1
Ios Cisco 12.3yk 12.3yk
Ios Cisco 12.3yf 12.3yf
Ios Cisco 12.1ec 12.1ec
Ios Cisco 12.3yt 12.3yt
Ios Cisco 12.2sy 12.2sy
Ios Cisco 12.2xk 12.2xk
Ios Cisco 12.1xh 12.1xh
Ios Cisco 12.3xb 12.3xb
Ios Cisco 12.2zj 12.2zj
Ios Cisco 12.0xa 12.0xa
Ios Cisco 12.1xu 12.1xu
Ios Cisco 12.0sc 12.0sc
Ios Cisco 12.3yg 12.3yg
Ios Cisco 12.3xu 12.3xu
Ios Cisco 12.2zd 12.2zd
Ios Cisco 12.4 12.4
Ios Cisco 12.1aa 12.1aa
Ios Cisco 12.0xn 12.0xn
Ios Cisco 12.2xc 12.2xc
Ios Cisco 12.2bc 12.2bc
Ios Cisco 12.1xx 12.1xx
Ios Cisco 12.2ze 12.2ze
Ios Cisco 12.2xs 12.2xs
Ios Cisco 12.2bw 12.2bw
Ios Cisco 12.4xa 12.4xa
Ios Cisco 12.2yy 12.2yy
Ios Cisco 12.2sz 12.2sz
Ios Cisco 12.3yx 12.3yx
Ios Cisco 12.1xd 12.1xd
Ios Cisco 12.2dx 12.2dx
Ios Cisco 12.1ez 12.1ez
Ios Cisco 12.3xq 12.3xq
Ios Cisco 12.2cx 12.2cx
Ios Cisco 12.3xh 12.3xh
Ios Cisco 12.1xq 12.1xq
Ios Cisco 12.0s 12.0s
Ios Cisco 12.2xf 12.2xf
Ios Cisco 12.3b 12.3b
Ios Cisco 12.4xb 12.4xb
Ios Cisco 12.2xv 12.2xv
Ios Cisco 12.2 12.2
Ios Cisco 12.1xa 12.1xa
Ios Cisco 12.0xg 12.0xg
Ios Cisco 12.0 12.0
Ios Cisco 12.2yz 12.2yz
Ios Cisco 12.2xa 12.2xa
Ios Cisco 12.0xi 12.0xi
Ios Cisco 12.2mc 12.2mc
Ios Cisco 12.2yx 12.2yx
Ios Cisco 12.2by 12.2by
Ios Cisco 12.2s 12.2s
Ios Cisco 12.2xt 12.2xt

Extended Description

Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components. When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution. Input validation is not the only technique for processing input, however. Other techniques attempt to transform potentially-dangerous input into something safe, such as filtering (CWE-790) - which attempts to remove dangerous inputs - or encoding/escaping (CWE-116), which attempts to ensure that the input is not misinterpreted when it is included in output to another component. Other techniques exist as well (see CWE-138 for more examples.) Input validation can be applied to:

Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data. Many properties of raw data or metadata may need to be validated upon entry into the code, such as:

Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation.

Note that “input validation” has very different meanings to different people, or within different classification schemes. Caution must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is referred to as input validation. Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred, and developers must be careful to understand the difference, including how input validation is not always sufficient to prevent vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a person’s last name is inserted into a query. The name “O’Reilly” would likely pass the validation step since it is a common last name in the English language. However, this valid name cannot be directly inserted into the database because it contains the “'” apostrophe character, which would need to be escaped or otherwise transformed. In this case, removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

Potential Mitigations

  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
  • Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
  • Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.

References