La source d'un “buffer overflow” peut être des données en entrée. Quand il vient du “Overflow Binary Resource File”, l'attaquant doit modifier/préparer le fichier binaire d'une telle façon que l'application, après avoir lu ce fichier, est devenue prédisposée à une attaque classique de “ Buffer overflow attack. La seule différence entre cette attaque et une classique est la source des données en entrée. Les exemples communs sont spécialement conçus pour les fichiers MP3, JPEG ou ANI, qui provoquent les “buffer overflows”.

L'application lit les 8 premiers caractères du fichier binaire.

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;
}

Le dossier conçu contient plus de 8 caractères.

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

Après un essai pour le lancer encore une fois, l'application finira avec :

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

Échec. Était-ce le “ 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

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

Oui, c'était le “ buffer overflow ” dans une fonction strcpy(). Pourquoi ? fread(b, sizeof(b), 1, f); - lit des caractères du stream f, sizeof (b) une fois, au buffer b. Cela semble OK. Pourtant il n'y a aucune place pour un '\0', qui termine le string. En exécutant strcpy(p,b), où les deux buffers sont égaux, un débordement survient. Ce qui le provoque est l'absence du caractère d'octet de terminaison nul dans un buffer b[]. La fonction strcpy() copiera dans le buffer p[] tout ce qui commence par b[0] et finissant sur l'octet nul. L'attaquant a avec succès accompli l'attaque de débordement de buffer en concevant manuellement un fichier spécial. Utilisez des fonctions équivalentes sûres, qui vérifient la longueur du buffer, dans la mesure du possible. À savoir :

• gets() → fgets()
• strcpy() → strncpy()
• strcat() → strncat()
• sprintf() → snprintf()
• Ces fonctions qui n'ont pas d'équivalents sûrs devraient être réécrites avec des contrôles de sécurité implémentés. Le temps passé sur cela profitera dans l'avenir. N'oubliez pas que vous devez le qu'une seule fois.
• Utilisez des compilateurs, qui sont en mesure d'identifier des fonctions à risque, des erreurs de logique et un vérifier si la mémoire est écrasée quand et où elle ne devrait pas l'être.

• http://capec.mitre.org/data/definitions/44.html