Difference between revisions of "Dangerous Function"

From OWASP
Jump to: navigation, search
m (Reverted edits by TrtrrOlcna (Talk) to last version by KirstenS)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:Fortify}}
 
{{Template:Fortify}}
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR Table of Contents]]
 
__TOC__
 
 
  
 
==Description==
 
==Description==
 
 
Functions that cannot be used safely should never be used.
 
Functions that cannot be used safely should never be used.
  
Line 127: Line 120:
  
 
==References==
 
==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
+
TBD
 
+
* [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
 
[[Category:FIXME|add links
  
Line 167: Line 155:
 
[[Category:Use of Dangerous API]]
 
[[Category:Use of Dangerous API]]
 
[[Category:API Abuse]]
 
[[Category:API Abuse]]
 +
[[Category:Vulnerability]]

Latest revision as of 12:00, 26 May 2009

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


This article includes content generously donated to OWASP by Fortify.JPG.

Last revision (mm/dd/yy): 05/26/2009

Vulnerabilities Table of Contents

Description

Functions that cannot be used safely should never be used.

Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account.

Risk Factors

TBD

Examples

  • C functions that don't check the size of the destination buffers, such as gets(), strcpy(), strcat(), printf()
  • The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer.
  • The >> operator is unsafe to use when reading into a character buffer because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.

Example program

See this simple C program :

main() {

       char  buffer[25];
       
       printf("\nEnter Text : ");
       gets(buffer);

}

It appears to be correct, but it posesses a security problem. If you enter a short piece of text such as "Hello", the above program works fine. But if the entered value is longer than the allocated buffer, such as the text "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", the program may crash due to a segfault, or otherwise behave inappropriately.

What happens when the above program runs

cmain() calls the main() procedure.

In Assembly

_cmain proc far           /* In C, all function names begins with an underscore */

xx

call _main

xx

_cmain endp

_main proc 

mov ebp, esp
add ebp, 19h               /* 19h = 25 dec.  Creates buffer array in the stack frame */
lea eax, strEnterText      /* Gets the address of the string "\nEnter Text : " */
push eax                   /* pushes this address to stack for printf function */

call _printf               /* calls the printf function */


push ebp                   /* pushes the address of the buffer array */

call _gets                 /* calls gets()  */

   /* The gets function stores the entered charecter from stdin to memory pointed by ebp  */

   /*  if the number of charecter got from stdin is greater than the SIZE of the buffer */
 
   /* the buffer overflow occurs. */

xxx

_main endp

As return addresses of all functions are stored on the stack, if the buffer array is overflowed, then the returned address of the functions may be overwritten by the user inputed data.


How this program can be exploited

Once the bounds of the array are known, text can be entered so that the return address on the stack is overwritten to point to a different location in memory which the program is not supposed to access at that time, such as other malicious code.

The length of the buffer could be easily discovered through trial-and-error.

You should never use a function which extracts data from the user without no bounds checking. A better alternative is "fgets".

To get input from stdin use this:

fgets(buffer,25,stdin);

Related Attacks


Related Vulnerabilities


Related Controls


Related Technical Impacts


References

TBD