CWE Glossary

CWE is a trademark of the MITRE Corporation.

Stay in touch

Application security insights and invitations to exclusive events in your inbox

Your data will stay confidential Private and Confidential

Improper Handling of Undefined Parameters [CWE-236]

This weakness describes a case when application uses undefined parameter, field, or argument.

Created: December 4, 2012
Latest Update: August 5, 2015

Table of Content

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

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.

  1. // Improper Handling of Undefined Parameters [CWE-236] vulnerable code example
  2. // (c) HTB Research
  3. #include "StdAfx.h"
  4. #ifdef WIN32
  5. #include <windows.h>
  6. #else
  7. #include <string.h>
  8. #endif
  9. #include <stdio.h>
  10. #define SERIAL "ABCD907341AB"
  12. void CompareStrings(char * DATA, char * DATA2)
  13. {
  14.         if(strcmp(DATA, DATA2) == 0)
  15.         {
  16.                 printf("The serial code is valid!\n"); 
  17.                 return;
  18.         } else {
  19.                 printf("The serial code is invalid!\n");
  20.         }      
  21.         return;
  22. }
  24. int CheckRegistration(char *InputKey)
  25. {
  26.         CompareStrings (SERIAL, InputKey);
  27.         return 0;
  28. }
  30. int main(int argc, char* argv[])
  31. {
  32.         // Call our function.
  33.         CheckRegistration (argv[1]);
  34.         return 0;
  35. }

The comparison results are shown on the following images:

CWE-236 PoC exploitation example
Figure - The user's entry code is invalid

CWE-236 PoC exploitation example
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.

CWE-236 PoC exploitation example
Figure - The application crashes due to an undefined parameter

CWE-236 PoC exploitation example
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 information, the weakness should be scored as C:P/I:N/A:N.

In case of a remote exploitation vector against client application, the CVSS score should be:
4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) – Medium severity.

Denial of service

If vulnerability is presented in a software and exploitation of it results in application crash, it should be scored as C:N/I:N/A:P. But if the vulnerability could be used to crash or reboot the entire system, it should be scored as C:N/I:N/A:C.

The following example can be used to score remotely exploitable vulnerability in a network service, which runs with SYSTEM privileges:
7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) – High severity.

Code execution

If there is a possibility of code execution, the CVSS score should be C:C/I:C/A:C. In case of remote exploitation in default installation of application and with no additional conditions, we recommend usage of the following CVSS metrics:
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C) – Critical severity.

We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.

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 []
  2. Nero MediaHome Server Multiple Remote DoS Vulnerabilities [HTB23130] []

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

↑ Back to Top
High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email
Let's Talk