Improper Handling of Undefined Parameters [CWE-236]

Improper Handling of Undefined Parameters describes a case when application uses undefined parameter, field, or argument.

Created: December 4, 2012
Latest Update: December 15, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Severity and CVSS Scoring
6. Mitigations
7. References

Want to have an in-depth understanding of all modern aspects of
Improper Handling of Undefined Parameters [CWE-236]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

This weakness occurs when software performs actions on parameters, fields, or arguments that are not defined or are unexpected. This error is usually spotted when certain actions are performed on arrays with arbitrary number of elements or keys. The impact of this weakness can vary depending on application design and exploitation conditions. The attacker might be able to crash the application, modify data or even execute arbitrary code.

We will use a simple example to demonstrate this vulnerability. The code below expects a serial number from a command line and compares it against the hardcoded value.

The comparison results are shown on the following images:


Figure - The user's entry code is invalid


Figure - The user's entry code is valid

Our example, however, does not perform checks on the number of input parameters before calling the CheckRegistration() function. If the application is executed without arguments, a value of NULL is passed as an "InputKey" argument of the CompareStrings() function, which is later used in the strcmp() call. As a result, the application crashes with exception code c0000005.


Figure - The application crashes due to an undefined parameter


Figure - The application crashes due to an undefined parameter

2. Potential impact

The attacker who controls input parameters can influence the application flaw. This can trigger an unexpected behavior of the application and lead to a crash, information leak, data tampering or code execution.

3. Attack patterns

There are no particular CAPEC attack patterns assigned to this weakness.

4. Affected software

This weakness can be introduced into the application during architecture, design, or implementation phase and is language independent. This means that any language can be susceptible to this issue.

5. Severity and CVSS Scoring

This weakness can have different impacts and should be scored in accordance to them.

Information disclosure

If there is a possibility to disclose certain parts of memory, the weakness should be scored as C:L/I:N/A:N.

In case of a remote attack against client application, the CVSS score is as follows:
5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] – Medium Severity.

Denial of service

If vulnerability is present in a software and exploitation of buffer overflow results in application crash it should be scored as C:N/I:N/A:H. But if the vulnerability could be used to crash or reboot the entire system it should be scored as S:C as well.

The following example can be used to score remotely exploitable vulnerability in a network service, which runs with SYSTEM privileges:
8.6 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H] – High Severity.

Code execution

If there is a possibility of code execution, the CVSS score should be C:H/I:H/A:H. For a remote attack vector, we recommend usage of the following CVSS metrics:
9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] – Critical Severity.

6. Mitigations

This type of weakness does not have particular mitigation techniques. Developers should carefully manage untrusted input and pay attention to arguments that are passed to the application.

7. References

1. CWE-236: Improper Handling of Undefined Parameters [cwe.mitre.org]
2. Nero MediaHome Server Multiple Remote DoS Vulnerabilities [HTB23130] [htbridge.com]

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.