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 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 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.
Examples
Application reads first 8 characters from 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;
}
Crafted file contaions more than 8 characters.
rezos@dojo-labs ~/owasp/binary $ cat file.bin
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Attempt to run one more time 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, definietly that was a buffer overflow in a strcpy()
function.
Why?
fread(b, sizeof(b), 1, f); - it 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.
During 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 special file.