This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Buffer Overflow via Environment Variables"

From OWASP
Jump to: navigation, search
(Description)
(Examples)
 
(One intermediate revision by the same user not shown)
Line 19: Line 19:
  
 
==Examples ==
 
==Examples ==
 
Furthermore the attacker performs the following steps:
 
* The attacker tries to find an environment variable which can be overwritten for instance by gathering information about the target
 
host (error pages, software's version number, hostname, etc.).
 
* The attacker manipulates the environment variable to contain excessive-length content to cause a buffer overflow.
 
* The attacker potentially leverages the buffer overflow to inject maliciously crafted code in an attempt to execute privileged command on the target environment.
 
  
  
 
'''Example1'''
 
'''Example1'''
  
Application below gets information about its run environment from environment variables.
+
The application below gets information about its run environment from environment variables.
  
 
<pre>
 
<pre>
Line 50: Line 44:
 
}
 
}
 
</pre>
 
</pre>
Application checks the value of the environment variable ''HOME'' (path to the home directory) and stores it. It is done by calling
+
The application checks the value of the environment variable ''HOME'' (path to the home directory) and stores it. It is done by calling the
getenv(3) library function in GNU/Linux. If return value of this function is different than NULL (NULL value means that variable
+
getenv(3) library function in GNU/Linux. If the return value of this function is different than NULL (NULL value means that variable
is not set), then message is created by calling sprintf(3). This function doesn't validate the length of the string, which is going
+
is not set), then a message is created by calling sprintf(3). This function doesn't validate the length of the string, which is going
 
to be written in the targer 64 char size buffer - h[].
 
to be written in the targer 64 char size buffer - h[].
  
Line 64: Line 58:
 
rezos@dojo-labs ~/owasp/buffer_overflow $ export HOME=`perl -e 'print "A"x128'`
 
rezos@dojo-labs ~/owasp/buffer_overflow $ export HOME=`perl -e 'print "A"x128'`
 
</pre>
 
</pre>
When we run program again, to the buffer h[64] is copied a message,
+
When we run program again, a message is copied  to the buffer h[64],
which has length of (assuming sizeof(char) = 1):
+
which has a length of (assuming sizeof(char) = 1):
 
<pre>
 
<pre>
 
strlen("Your home directory is:  !") + strlen(ptr_h) = 28 + 128 = 156
 
strlen("Your home directory is:  !") + strlen(ptr_h) = 28 + 128 = 156
Line 77: Line 71:
 
rezos@dojo-labs /home/rezos/owasp/buffer_overflow $
 
rezos@dojo-labs /home/rezos/owasp/buffer_overflow $
 
</pre>
 
</pre>
Program ended with memory segmentation fault, buffer h[] was overwritten.
+
The program ended with memory segmentation fault, and buffer h[] was overwritten.
 
Using environment variables themselves is not a problem. The real problem is when application lacks their proper validation - size and content. More information about errors related to buffer overflows may be found in the [[Buffer_overflow_attack]] article.
 
Using environment variables themselves is not a problem. The real problem is when application lacks their proper validation - size and content. More information about errors related to buffer overflows may be found in the [[Buffer_overflow_attack]] article.
  
Code injection is performed in the same common way like in buffer overflow attacks with only one difference. The shellcode is placed in environment variable(s).
+
Code injection is performed in the same way as in buffer overflow attacks with only one difference; the shellcode is placed in environment variable(s).
  
 
==Related Threats==
 
==Related Threats==

Latest revision as of 11:53, 4 August 2008

This is an Attack. To view all attacks, please see the Attack Category page.


Description

This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.

The following conditions must be met to conduct successful attack:

  • The application uses environment variables.
  • The environment variable exposed to the user is vulnerable to a buffer overflow.
  • The vulnerable environment variable uses untrusted data.
  • Tainted data used in the environment variables is not properly validated. For instance boundary checking is not done before copying

the input data to a buffer.

The attacker performs the following steps:

  • The attacker tries to find an environment variable which can be overwritten, by gathering information about the target

host (error pages, software's version number, hostname, etc.).

  • The attacker manipulates the environment variable to contain excessive-length content to cause a buffer overflow.
  • The attacker leverages the buffer overflow to inject maliciously crafted code in an attempt to execute privileged command on the target environment.

Examples

Example1

The application below gets information about its run environment from environment variables.

rezos@dojo-labs ~/owasp/buffer_overflow $ cat bo_env.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
       char *ptr_h;
       char h[64];

       ptr_h = getenv("HOME");
       if(ptr_h != NULL) {
               sprintf(h, "Your home directory is: %s !", ptr_h);
               printf("%s\n", h);
       }

       return 0;
}

The application checks the value of the environment variable HOME (path to the home directory) and stores it. It is done by calling the getenv(3) library function in GNU/Linux. If the return value of this function is different than NULL (NULL value means that variable is not set), then a message is created by calling sprintf(3). This function doesn't validate the length of the string, which is going to be written in the targer 64 char size buffer - h[].

Common program execution:

rezos@dojo-labs ~/owasp/buffer_overflow $ ./bo_env
Your home directory is: /home/rezos !

Now let's change the value of HOME to 128 'A' characters.

rezos@dojo-labs ~/owasp/buffer_overflow $ export HOME=`perl -e 'print "A"x128'`

When we run program again, a message is copied to the buffer h[64], which has a length of (assuming sizeof(char) = 1):

strlen("Your home directory is:  !") + strlen(ptr_h) = 28 + 128 = 156
rezos@dojo-labs /home/rezos/owasp/buffer_overflow $ ./bo_env
Your home directory is:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
!
Segmentation fault
rezos@dojo-labs /home/rezos/owasp/buffer_overflow $

The program ended with memory segmentation fault, and buffer h[] was overwritten. Using environment variables themselves is not a problem. The real problem is when application lacks their proper validation - size and content. More information about errors related to buffer overflows may be found in the Buffer_overflow_attack article.

Code injection is performed in the same way as in buffer overflow attacks with only one difference; the shellcode is placed in environment variable(s).

Related Threats

Related Attacks

Related Vulnerabilities

Related Countermeasures

  • Category:Input Validation
  • Do not expose environment variable to the user.
  • Do not use untrusted data in your environment variables.

Categories