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

**Bktero** · 29/05/2013, 07h55

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

**Aspic** · 29/05/2013, 10h21

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

@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)" ?

**Bktero** · 29/05/2013, 10h56

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void with_array(void)
{
    int a[10] = {0};
    a[10] = 50; // overflow
}

Il y arrive aussi sur ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

**ternel** · 29/05/2013, 10h59

En effet, c'est bon à prendre.

**Metalman** · 29/05/2013, 11h24

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)

**Bktero** · 29/05/2013, 14h11

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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>)

**Metalman** · 29/05/2013, 14h26

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

**ternel** · 29/05/2013, 14h26

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.

**kwariz** · 29/05/2013, 14h38

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 ...

**Aspic** · 29/05/2013, 16h52

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

Je regarderais ca ce soir quand j'aurais un peu de temps.

**Bktero** · 29/05/2013, 17h38

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

**Aspic** · 29/05/2013, 17h44

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

)