Difference between revisions of "Overflow Binary Resource File"

From OWASP
Jump to: navigation, search
(New page: {{Template:Attack}} ==Description== The source of the buffer overflows may be input data generally. When it comes about Overflow Binary Resource File the attacker has to modify/prepare bi...)
 
 
(18 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
 +
<br>
 +
[[Category:OWASP ASDR Project]]
 +
 +
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
==Description==
 
==Description==
The source of the buffer overflows may be input data generally.
+
The source of a buffer overflow may be input data.
When it comes about Overflow Binary Resource File the attacker has to modify/prepare binary file in such a way, that the
+
When it comes from the  Overflow Binary Resource File, the attacker has to modify/prepare the binary file in such a way that the
application after reading this file is becoming prone to a classic buffer overflow attack. The only difference between this attack
+
application, after reading this file, has become prone to a classic [[Buffer overflow attack]]. The only difference between this attack
and the classic one, is the source of the input data. Common examples are specially crafted MP3, JPEG or ANI files, which causes buffer overflows.
+
and the classic one is the source of the input data. Common examples are specially crafted MP3, JPEG or ANI files, which cause buffer overflows.
  
==Examples ==
+
==Risk Factors==
 +
TBD
  
Application reads first 8 characters from binary file.
+
==Examples ==
 +
The application reads the first 8 characters from the binary file.
 
<pre>
 
<pre>
 
rezos@dojo-labs ~/owasp/binary $ cat read_binary_file.c
 
rezos@dojo-labs ~/owasp/binary $ cat read_binary_file.c
Line 32: Line 39:
 
}
 
}
 
</pre>
 
</pre>
Crafted file contaions more than 8 characters.
+
The crafted file contains more than 8 characters.
 
<pre>
 
<pre>
 
rezos@dojo-labs ~/owasp/binary $ cat file.bin
 
rezos@dojo-labs ~/owasp/binary $ cat file.bin
 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 
</pre>
 
</pre>
Attempt to run one more time application will end with:
+
After an attempt to run one more time, the application will end with:
 
<pre>
 
<pre>
 
rezos@dojo-labs ~/owasp/binary $ ./read_binary_file
 
rezos@dojo-labs ~/owasp/binary $ ./read_binary_file
 
Segmentation fault
 
Segmentation fault
 
</pre>
 
</pre>
failure. Was it buffer overflow?
+
Failure. Was it buffer overflow?
 
<pre>
 
<pre>
 
rezos@dojo-labs ~/owasp/binary $ gdb -q ./read_binary_file
 
rezos@dojo-labs ~/owasp/binary $ gdb -q ./read_binary_file
Line 52: Line 59:
 
0xb7e4b9e3 in strcpy () from /lib/libc.so.6
 
0xb7e4b9e3 in strcpy () from /lib/libc.so.6
 
</pre>
 
</pre>
Yes, definietly that was a buffer overflow in a strcpy() function.
+
Yes, that was a buffer overflow in a strcpy() function.
  
 
Why?
 
Why?
  
fread(b, sizeof(b), 1, f); - it reads characters from the stream f, sizeof(b) once, to the buffer b. It looks OK.
+
fread(b, sizeof(b), 1, f); - reads characters from the stream f, sizeof(b) once, to the buffer b. It looks OK.
 
However there is no room for a '\0', which terminates the string.
 
However there is no room for a '\0', which terminates the string.
  
During executing strcpy(p, b); where both buffers are equal overflow takes place. What causes it is the absence of the
+
Whiile executing strcpy(p, b); where both buffers are equal, overflow takes place. What causes it is the absence of the
 
null byte/terminating character in a buffer b[]. The strcpy() function will copy into the buffer p[] everything starting
 
null byte/terminating character in a buffer b[]. The strcpy() function will copy into the buffer p[] everything starting
in b[0] and ending on the null byte. The attacker has successfully conducted the buffer overflow attack by crafting
+
in b[0] and ending on the null byte. The attacker has successfully conducted the buffer overflow attack by crafting a
 
special file.
 
special file.
  
References:
+
* Use safe equivalent functions, which check the buffer length, whenever possible.
* http://capec.mitre.org/data/definitions/44.html
+
  
==Related Threats==
+
Namely:
 +
*gets() -> fgets()
 +
*strcpy() -> strncpy()
 +
*strcat() -> strncat()
 +
*sprintf() -> snprintf()
  
* [[:Category:Command_Execution]]
+
* Those functions which don't have safe equivalents should be rewritten with safe checks implemented. Time spent on that will benefit in the future. Remember that you have to do it only once.
  
==Related Attacks==
+
* Use compilers, which are able to identify unsafe functions, logic errors, and check if the memory is overwritten when and where it shouldn't be.
  
* [[Buffer_overflow_attack]]
+
==Related [[Threat Agents]]==
* [[Format_string_attack]]
+
* [[:Category:Command_Execution]]
  
==Related Vulnerabilities==
+
==Related [[Attacks]]==
 +
* [[Buffer overflow attack]]
 +
* [[Format string attack]]
  
* [[Format string]]
+
==Related [[Vulnerabilities]]==
 +
* [[Format String]]
 
* [[Heap overflow]]
 
* [[Heap overflow]]
  
==Related Countermeasures==
+
==Related [[Controls]]==
 +
* [[Bounds Checking]]
 +
* [[Safe Libraries]]
 +
* [[Static Code Analysis]]
 +
* [[Executable space protection]]
 +
* [[Address space layout randomization (ASLR)]]
 +
* [[Stack-smashing Protection (SSP)]]
  
1)
 
Use safe equivalent functions, which check the buffers length,
 
whenever it's possible.
 
  
Namely:
+
==References==
*gets() -> fgets()
+
* http://capec.mitre.org/data/definitions/44.html
*strcpy() -> strncpy()
+
*strcat() -> strncat()
+
*sprintf() -> snprintf()
+
 
+
2)
+
These functions which doesn't have their safe equivalents should be rewritten
+
with safe checks implemented. Time spent on that will benefit in the future.
+
Remember that you have to do it only once.
+
 
+
3)
+
Use compilers, which are able to identify unsafe functions, logic errors and
+
check if the memory is overwritten when and where it shouldn't be.
+
  
==Categories==
 
  
 
[[Category:Data Structure Attacks]]
 
[[Category:Data Structure Attacks]]
 
[[Category:Attack]]
 
[[Category:Attack]]

Latest revision as of 06:46, 23 April 2009

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




Last revision (mm/dd/yy): 04/23/2009

Description

The source of a buffer overflow may be input data. When it comes from the Overflow Binary Resource File, the attacker has to modify/prepare the binary file in such a way that the application, after reading this file, has become prone to a classic Buffer overflow attack. The only difference between this attack and the classic one is the source of the input data. Common examples are specially crafted MP3, JPEG or ANI files, which cause buffer overflows.

Risk Factors

TBD

Examples

The application reads the first 8 characters from the binary file.

rezos@dojo-labs ~/owasp/binary $ cat read_binary_file.c
#include <stdio.h>
#include <string.h>

int main(void)
{
       FILE *f;
       char p[8];
       char b[8];

       f = fopen("file.bin", "r");
       fread(b, sizeof(b), 1, f);
       fclose(f);

       strcpy(p, b);

       printf("%s\n", p);

       return 0;
}

The crafted file contains more than 8 characters.

rezos@dojo-labs ~/owasp/binary $ cat file.bin
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

After an attempt to run one more time, the application will end with:

rezos@dojo-labs ~/owasp/binary $ ./read_binary_file
Segmentation fault

Failure. Was it buffer overflow?

rezos@dojo-labs ~/owasp/binary $ gdb -q ./read_binary_file
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/rezos/owasp/binary/read_binary_file

Program received signal SIGSEGV, Segmentation fault.
0xb7e4b9e3 in strcpy () from /lib/libc.so.6

Yes, that was a buffer overflow in a strcpy() function.

Why?

fread(b, sizeof(b), 1, f); - reads characters from the stream f, sizeof(b) once, to the buffer b. It looks OK. However there is no room for a '\0', which terminates the string.

Whiile executing strcpy(p, b); where both buffers are equal, overflow takes place. What causes it is the absence of the null byte/terminating character in a buffer b[]. The strcpy() function will copy into the buffer p[] everything starting in b[0] and ending on the null byte. The attacker has successfully conducted the buffer overflow attack by crafting a special file.

  • Use safe equivalent functions, which check the buffer length, whenever possible.

Namely:

  • gets() -> fgets()
  • strcpy() -> strncpy()
  • strcat() -> strncat()
  • sprintf() -> snprintf()
  • Those functions which don't have safe equivalents should be rewritten with safe checks implemented. Time spent on that will benefit in the future. Remember that you have to do it only once.
  • Use compilers, which are able to identify unsafe functions, logic errors, and check if the memory is overwritten when and where it shouldn't be.

Related Threat Agents

Related Attacks

Related Vulnerabilities

Related Controls


References