[C] Méthodes détection buffer overflow/overrun

Version imprimable

Voir 40 message(s) de cette discussion en une page

Je suis la conversation d'un peu loin et je me dis que j'allais tester ce que donne ton code dans Dr Memory. J'ai rajouté un free() pour ne laisser que l'erreur d'accès hors des bornes de la zone malloqué :

Code:

1
2
3
4
5
6
int main(void)
{
    int*a = (int*)malloc(10*sizeof(int));
    a[10] = 50; // overflow
    free(a);
}

J'obtiens comme rapport d'erreurs :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Dr. Memory version 1.5.1 build 6 built on Feb 25 2013 00:45:31
Application cmdline: ""D:\Users\pgradot\Documents\C\main.exe""
Recorded 75 suppression(s) from default C:\Program Files (x86)\Dr. Memory\bin\suppress-default.txt
 
Error #1: UNADDRESSABLE ACCESS: writing 0x003b0f80-0x003b0f84 4 byte(s)
# 0 main    
Note: @0:00:00.251 in thread 4644
Note: next higher malloc: 0x003b1938-0x003b1b58
Note: refers to 1 byte(s) beyond last valid byte in prior malloc
Note: prev lower malloc:  0x003b0f58-0x003b0f80
Note: instruction: mov    $0x00000032 -> (%eax)
 
DUPLICATE ERROR COUNTS:
 
SUPPRESSIONS USED:
 
ERRORS FOUND:
      1 unique,     1 total unaddressable access(es)
      0 unique,     0 total uninitialized access(es)
      0 unique,     0 total invalid heap argument(s)
      0 unique,     0 total GDI usage error(s)
      0 unique,     0 total warning(s)
      0 unique,     0 total,      0 byte(s) of leak(s)
      0 unique,     0 total,      0 byte(s) of possible leak(s)
ERRORS IGNORED:
     60 still-reachable allocation(s)
         (re-run with "-show_reachable" for details)
Details: d:\Users\pgradot\AppData\Roaming\Dr. Memory\DrMemory-main.exe.3224.000\results.txt

En revanche, il n'est pas plus capable que valgrind de détecter l'erreur si on accède hors des bornes d'un vrai tableau...

29/05/2013, 10h21
Aspic

Citation:

Envoyé par Franck.H

Bin il te faut rien de plus que free, malloc et ralloc pour monter tout ca et quelques conditions logique bien entendu mais si tu n'as pas le droit de procéder de la sorte soit :mouarf:

Le problème c'est que dans ton exemple, tu as définie des fonctions d'ajouts et de suppressions d'un entier évitant ainsi l'utilisation de l'opérateur []. Donc tu peux tout contrôler dont les overflows/underflows si on utilise tes fonctions ;)

Dans mon cas, n'ayant pas accès au code source (en fait c'est faux, j'y ai accès mais je ne dois pas le modifier), je n'ai accès qu'aux surcharges des fonctions d'alloc mais je ne peux pas overloader l'opérateur [] en C ... :(

Et puis le prototype de malloc est :

Code:

void* malloc(size_t size)

Si par exemple, j'ai 40 dans size, aucun moyen de savoir si il veut 10 entiers, 40 caractères ou une structure complexe de 40 octets.

Ou alors j'ai pas compris ton idée :mouarf:

@Bktero: Oui je sais que Dr Memory sait détecter ce genre d'erreur, d'ailleurs je me demande bien comment il fait ^^ D'ailleurs ca veut dire quoi" 60 still-reachable allocation(s)" ?
29/05/2013, 10h56
Bktero
Je viens de tester à l'instant un outil découvert il y a peu, cppcheck.

Comme répertoire de travail, je lui ai donné mon dossier avec mes bouts de code tests C, notamment ceux pour Developpez. Il m'a détecté une erreur sur le code (alors que je ne cherchais pas du tout à le tester sur ce problème là, c'est une découverte due au hasard ^^) :
Code:

1 2 3 4 5 void with_array(void) { int a[10] = {0}; a[10] = 50; // overflow }
Il y arrive aussi sur ça :
Code:

1 2 3 4 5 6 7 8 void more_subttle(void) { int a[10] = {0}; for(int i=0; i < 11; i++) { a[i]= i; } }
Je crois que je vais bien aimer cet outil !
29/05/2013, 10h59
ternel

En effet, c'est bon à prendre.
29/05/2013, 11h24
Metalman

Le "60 still reachables" signifie que tu as fait 60 mallocs et que tu ne les a pas free !
Pour les connaitre, tu devrais compiler avec les habituels flags de debug : -g -g3 -ggdb, puis lancer DrMemory sur le binaire résultat !
Ca t'affichera le fichier et la ligne exacte où il y a un malloc non free.
Par contre, pour corriger cela... il faut bien regarder dans toute la chaine fonctions laquelle demande à allouer et ne libère pas !

(Ce qui serait intéressant à vérifier maintenant, c'est si les allocations mémoires windoziennes sont "aussi" vérifiées (en pur C/Windows) par DrMemory)

Non, l'"erreur" n'est pas liée à cela...... car le free() est bien présent ! Et aussi parce que 4 bytes par int * 10 int = 40 bytes donc 60 ne collent pas ^^

De plus, si je commente le free() et repasse le binaire dans drmemory, j'obtiens vraiment une erreur :
Code:

1 2 Error #2: LEAK 40 direct bytes 0x00660f58-0x00660f80 + 0 indirect bytes # 0 main
Les still reachables semblent être des erreurs non graves, voir par exemple cette discussion de Stackoverflow.
EDIT : ou le point 1 de la doc de drmemory.

En ré-exécutant avec l'option indiquée, cela semble venir de dll. Extrait :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 REACHABLE LEAK 206 direct bytes 0x004a5f48-0x004a6016 + 0 indirect bytes REACHABLE LEAK 2748 direct bytes 0x004a6230-0x004a6cec + 0 indirect bytes REACHABLE LEAK 1152 direct bytes 0x006b09f0-0x006b0e70 + 0 indirect bytes REACHABLE LEAK 544 direct bytes 0x006b1938-0x006b1b58 + 0 indirect bytes REACHABLE LEAK 2897 direct bytes 0x006b1b60-0x006b26b1 + 0 indirect bytes REACHABLE LEAK 8 direct bytes 0x006b2f90-0x006b2f98 + 0 indirect bytes # 0 msvcrt.dll!_calloc_crt # 1 msvcrt.dll!_cwild # 2 msvcrt.dll!__getmainargs # 3 __mingw_CRTStartup # 4 ntdll.dll!RtlInitializeExceptionChain +0x62 (0x777e9ef2 <ntdll.dll+0x39ef2>) # 5 ntdll.dll!RtlInitializeExceptionChain +0x35 (0x777e9ec5 <ntdll.dll+0x39ec5>)

29/05/2013, 14h26
Metalman

Avec une DLL....
Je me souviens qu'à une époque on soupçonnait printf de faire 1 leak, mais en y repensant, cela doit faire partie des "still reachable" en effet.
Ca doit être une soixantaine de pointeurs encore référencés quelque part dans des globales.

EDIT : Bon bah le post suivant a l'air d'appuyer cette idée
29/05/2013, 14h26
ternel

Il me semble avoir lu que sous linux, il reste des unreachables avec certaines parties de la glibc.
Ce serait lié à des globales non déchargées (parce que la glibc reste utilisée partout)
Il était dit que ces unreachables n'augmentent pas, et ne devrait(?) pas poser de problèmes.

Cela dit, vérifie quand même ton code, mieux vaut être sûr.
29/05/2013, 14h38
kwariz

Oui, les outils comme valgrind ne peuvent (ne pourront jamais ?) pas ne pas donner de faux positifs. Certains sont référencés et cachés et dans la grande majorité des cas sont totalement inoffensifs (du moins ce sont les tous derniers à considérer lorsqu'on a un problème mémoire ...).
Certaines bibliothèques comme le GLib offrent la possibilité de modifier leur comportement via des variables d'environnement pour être une peu plus valgrind friendly. Je ne sais pas ce qu'il en est sur la plateforme win32/win64 ...
29/05/2013, 16h52
Aspic

D'accord, pour l'explication du still-reachable. en gros c'est pas (très) grave.

CppCheck, ca à l'air pas mal comme outil, j'espère qu'il est compatible MinGW sous windows :aie:

Je regarderais ca ce soir quand j'aurais un peu de temps. :D
29/05/2013, 17h38
Bktero

Citation:

CppCheck, ca à l'air pas mal comme outil, j'espère qu'il est compatible MinGW sous windows

Je suis sous Windows et utilise Codeblocks avec MinGW ;)
29/05/2013, 17h44
Aspic

Citation:

Envoyé par Bktero

Je suis sous Windows et utilise Codeblocks avec MinGW ;)

Il parait qu'avec CodeBlock, le plugin cppcheck est natif, pourtant je le trouve pas (faut dire que je suis encore à la version 8.02, c'est peut être pour ca :aie:)
29/05/2013, 18h23
Bktero

J'ai aussi lu ça sur le site de cppcheck après mon précédent message. J'ai une version récente de Codeblocks et il y est ;)
30/05/2013, 10h03
Aspic

Citation:

Envoyé par Bktero

J'ai aussi lu ça sur le site de cppcheck après mon précédent message. J'ai une version récente de Codeblocks et il y est ;)

C'est pas très grave, j'installerais le plugin manuellement ;)

Voir 40 message(s) de cette discussion en une page