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]

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

Improper Handling of Undefined Parameters [CWE-236]

Created: December 4, 2012
Latest Update: January 10, 2019

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"
  11.  
  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. }
  23.  
  24. int CheckRegistration(char *InputKey)
  25. {
  26.         CompareStrings (SERIAL, InputKey);
  27.         return 0;
  28. }
  29.  
  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 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 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
Share
Let's Talk