Difference between revisions of "Missing parameter"

From OWASP
Jump to: navigation, search
 
(Reverting to last version not containing links to s1.shard.jp)
 
(18 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 +
{{Template:Vulnerability}}
 +
{{Template:SecureSoftware}}
  
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
{{Template:SecureSoftware}}
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Overview==
+
==Description==
  
 
If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well.
 
If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well.
  
==Consequences ==
+
'''Consequences'''
  
* Authorization: There is the potential for arbitrary code execution with privileges of the vulnerable program if function parameter list is exhausted.
+
* Authorization: There is the potential for arbitrary code execution with privileges of the vulnerable program if the  function parameter list is exhausted.
 +
* Availability: Potentially a program could fail if it needs more arguments then are available.
  
* Availability: Potentially a program could fail if it needs more arguments then are available.
+
'''Exposure period'''
  
==Exposure period ==
+
* Implementation: This is a simple logical flaw created at implementation time.
  
* Implementation: This is a simple logical flaw created at implementation time.
+
'''Platform'''
  
==Platform ==
+
* Languages: C or C++
 +
* Operating platforms: Any
  
* Languages: C or C++
+
'''Required resources'''
 
+
* Operating platforms: Any
+
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
High
 
High
  
==Avoidance and mitigation ==
+
This issue can be simply combated with the use of proper build process.
  
* Implementation: Forward declare all functions. This is the recommended solution. Properly forward declaration of all used functions will result in a compiler error if too few arguments are sent to a function.
+
==Risk Factors==
  
==Discussion ==
+
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
 +
* Discuss the technical impact of a successful exploit of this vulnerability
 +
* Consider the likely [business impacts] of a successful attack
  
This issue can be simply combated with the use of proper build process.
 
  
==Examples ==
+
==Examples==
  
 
In C or C++:
 
In C or C++:
  
 +
<pre>
 
foo_funct(one, two);
 
foo_funct(one, two);
+
 
 
void foo_funct(int one, int two, int three) {
 
void foo_funct(int one, int two, int three) {
 
   printf("1) %d\n2) %d\n3) %d\n", one, two, three);
 
   printf("1) %d\n2) %d\n3) %d\n", one, two, three);
 
}
 
}
 +
</pre>
 +
 
This can be exploited to disclose information with no work whatsoever. In fact, each time this function is run, it will print out the next 4 bytes on the stack after the two numbers sent to it.
 
This can be exploited to disclose information with no work whatsoever. In fact, each time this function is run, it will print out the next 4 bytes on the stack after the two numbers sent to it.
  
 
Another example in C/C++ is:
 
Another example in C/C++ is:
  
 +
<pre>
 
void some_function(int foo, ...) {
 
void some_function(int foo, ...) {
 
     int a[3], i;
 
     int a[3], i;
Line 69: Line 75:
 
     some_function(17, 42);
 
     some_function(17, 42);
 
}
 
}
==Related problems ==
+
</pre>
  
Not available.
+
==Related [[Attacks]]==
  
==Categories ==
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
[[Category:Vulnerability]]
 
  
[[Category:General Logic Errors]]
+
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* Implementation: Forward declare all functions. This is the recommended solution. Properly forward declaration of all used functions will result in a compiler error if too few arguments are sent to a function.
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
 +
 
 +
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
 +
* http://www.link1.com
 +
* [http://www.link2.com Title for the link2]
 +
 
 +
[[Category:FIXME|add links
 +
 
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 
 +
Availability Vulnerability
 +
 
 +
Authorization Vulnerability
 +
 
 +
Authentication Vulnerability
 +
 
 +
Concurrency Vulnerability
 +
 
 +
Configuration Vulnerability
 +
 
 +
Cryptographic Vulnerability
 +
 
 +
Encoding Vulnerability
 +
 
 +
Error Handling Vulnerability
 +
 
 +
Input Validation Vulnerability
 +
 
 +
Logging and Auditing Vulnerability
 +
 
 +
Session Management Vulnerability]]
 +
 
 +
__NOTOC__
 +
 
 +
 
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 +
[[Category:General Logic Error Vulnerability]]
 +
[[Category:OWASP_CLASP_Project]]
 +
[[Category:Implementation]]

Latest revision as of 07:50, 3 June 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.



Last revision (mm/dd/yy): 06/3/2009

Vulnerabilities Table of Contents

Description

If too few arguments are sent to a function, the function will still pop the expected number of arguments from the stack. Potentially, a variable number of arguments could be exhausted in a function as well.

Consequences

  • Authorization: There is the potential for arbitrary code execution with privileges of the vulnerable program if the function parameter list is exhausted.
  • Availability: Potentially a program could fail if it needs more arguments then are available.

Exposure period

  • Implementation: This is a simple logical flaw created at implementation time.

Platform

  • Languages: C or C++
  • Operating platforms: Any

Required resources

Any

Severity

High

Likelihood of exploit

High

This issue can be simply combated with the use of proper build process.

Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


Examples

In C or C++:

foo_funct(one, two);

void foo_funct(int one, int two, int three) {
  printf("1) %d\n2) %d\n3) %d\n", one, two, three);
}

This can be exploited to disclose information with no work whatsoever. In fact, each time this function is run, it will print out the next 4 bytes on the stack after the two numbers sent to it.

Another example in C/C++ is:

void some_function(int foo, ...) {
    int a[3], i;
    va_list ap;

    va_start(ap, foo);
	for (i = 0;  i < sizeof(a) / sizeof(int);  i++)
        a[i] = va_arg(ap, int);
    va_end(ap);
}

int main(int argc, char *argv[]) {
    some_function(17, 42);
}

Related Attacks


Related Vulnerabilities


Related Controls

  • Implementation: Forward declare all functions. This is the recommended solution. Properly forward declaration of all used functions will result in a compiler error if too few arguments are sent to a function.


Related Technical Impacts


References

Note: A reference to related CWE or CAPEC article should be added when exists. Eg: