Exemplarische Vorgehensweise: Verwenden des Address Sanitizer-Features „Continue on Error“ zum Ermitteln von Problemen mit der Arbeitsspeichersicherheit
Erstellen Sie in dieser exemplarischen Vorgehensweise überprüfte Builds, die Speichersicherheitsfehler finden und melden.
Speichersicherheitsfehler wie out-of-bounds memory reads and writes, using memory after it been freed, NULL pointer deeferences, and so on, are a top concern for C/C++ code. Address Sanitizer (ASAN) ist eine Compiler- und Laufzeittechnologie, die diese Arten von schwer zu findenden Fehlern verfügbar macht, und führt sie mit null falsch positiven Ergebnissen durch. Eine Übersicht über ASAN finden Sie unter AddressSanitizer.
Continue On Error (COE) ist ein neues ASAN-Feature, das Speichersicherheitsfehler automatisch diagnostizieren und meldet, während Ihre App ausgeführt wird. Wenn Ihr Programm beendet wird, wird eine Zusammenfassung der eindeutigen Speichersicherheitsfehler an stdout, stderroder an eine Protokolldatei Ihrer Wahl ausgegeben. Wenn Sie einen standardmäßigen C++-überprüften Build mit -fsanitizer=address, Aufrufe an Allocators, Deallocators wie free, memcpy, memsetusw. erstellen, werden an die ASAN-Laufzeit weitergeleitet. Die ASAN-Laufzeit stellt die gleiche Semantik für diese Funktionen bereit, überwacht jedoch, was mit dem Speicher passiert. ASAN diagnostiziert und meldet ausgeblendete Speichersicherheitsfehler mit null falsch positiven Ergebnissen, während Ihre App ausgeführt wird.
Ein erheblicher Vorteil von COE ist, dass Ihr Programm im Gegensatz zum vorherigen ASAN-Verhalten nicht mehr ausgeführt wird, wenn der erste Speicherfehler gefunden wird. Stattdessen notiert ASAN den Fehler, und Ihre App wird weiterhin ausgeführt. Nach dem Beenden der App wird eine Zusammenfassung aller Speicherprobleme ausgegeben.
Es empfiehlt sich, einen überprüften Build Ihrer C- oder C++-App mit aktiviertem ASAN zu erstellen und dann Ihre App in Ihrer Testumgebung auszuführen. Wenn Ihre Tests die Codepfade in Ihrer App ausführen, die nach Fehlern suchen, werden Sie auch herausfinden, ob diese Codepfade Speichersicherheitsprobleme enthalten, ohne die Tests zu beeinträchtigen.
Nach Abschluss der App erhalten Sie eine Zusammenfassung der Speicherprobleme. Mit COE können Sie eine vorhandene Anwendung in einer begrenzten Produktion kompilieren und bereitstellen, um Speichersicherheitsprobleme zu finden. Sie können den überprüften Build für Tage ausführen, um den Code vollständig auszuführen, obwohl die App aufgrund der ASAN-Instrumentierung langsamer ausgeführt wird.
Sie können dieses Feature verwenden, um ein neues Versandtor zu erstellen. Wenn alle vorhandenen Tests bestehen, aber COE einen Speichersicherheitsfehler oder einen Verlust meldet, senden Sie den neuen Code nicht, oder integrieren Sie ihn in eine übergeordnete Verzweigung.
Stellen Sie keinen Build mit aktiviertem COE in der Produktion bereit! COE soll nur in Test- und Entwicklungsumgebungen verwendet werden. Sie sollten keinen ASAN-aktivierten Build in der Produktion verwenden, da die Leistungsauswirkungen der Zur Erkennung von Speicherfehlern hinzugefügten Instrumentierung, das Risiko, die interne Implementierung verfügbar zu machen, wenn Fehler gemeldet werden, und um zu vermeiden, den Oberflächenbereich möglicher Sicherheitsausnutzungen zu erhöhen, indem sie die Bibliotheksfunktionen versenden, die ASAN durch die Speicherzuweisung ersetzt, freigeben, Und so weiter.
In den folgenden Beispielen erstellen Sie überprüfte Builds und legen eine Umgebungsvariable fest, um die Adressbereinigungsinformationen auszugeben, um stdout die Speichersicherheitsfehler anzuzeigen, die ASAN meldet.
Um diese exemplarische Vorgehensweise abzuschließen, benötigen Sie Visual Studio 2022 17.6 oder höher, wobei die Desktopentwicklung mit installierter C++-Workload installiert ist.
In diesem Beispiel erstellen Sie einen Build mit AKTIVIERTem ASAN, um zu testen, was geschieht, wenn Arbeitsspeicher doppelt freigegeben wird. ASAN erkennt diesen Fehler und meldet ihn. In diesem Beispiel wird das Programm weiterhin ausgeführt, nachdem der Fehler erkannt wurde, was zu einem zweiten Fehler führt, indem arbeitsspeicher verwendet wird, der freigegeben wurde. Eine Zusammenfassung der Fehler wird ausgegeben stdout , wenn das Programm beendet wird.
Erstellen Sie das Beispiel:
Öffnen Sie eine Entwickler-Eingabeaufforderung: Öffnen Sie das Startmenü , geben Sie "Entwicklertools" ein, und wählen Sie die neueste Eingabeaufforderung aus der Liste der Übereinstimmungen aus, z . B. die Eingabeaufforderung für Entwickler für VS 2022 .
Erstellen Sie ein Verzeichnis auf Ihrem Computer, um dieses Beispiel auszuführen. Beispiel:
%USERPROFILE%\Desktop\COE.Erstellen Sie in diesem Verzeichnis eine leere Quelldatei. Beispiel:
doublefree.cppFügen Sie den folgenden Code in die Datei ein:
C++#include <stdio.h> #include <stdlib.h> void BadFunction(int *pointer) { free(pointer); free(pointer); // double-free! } int main(int argc, const char *argv[]) { int *pointer = static_cast<int *>(malloc(4)); BadFunction(pointer); // Normally we'd crash before this, but with COE we can see heap-use-after-free error as well printf("\n\n******* Pointer value: %d\n", *pointer); return 1; }
Im vorherigen Code pointer wird zweimal freigegeben. Dies ist ein unvorhergesehenes Beispiel, aber doppelte Freistellen sind ein einfacher Fehler, um in komplexerem C++-Code zu machen.
Erstellen Sie einen Build des vorherigen Codes mit aktiviertem COE mit den folgenden Schritten:
- Kompilieren Sie den Code in der Entwickler-Eingabeaufforderung, die Sie zuvor geöffnet haben:
cl -fsanitize=address -Zi doublefree.cpp. Der-fsanitize=addressSchalter aktiviert ASAN und-Zierstellt eine separate PDB-Datei, die zum Anzeigen von Informationen zum Speicherfehlerspeicherort verwendet wird. - Senden Sie die ASAN-Ausgabe,
stdoutindem Sie dieASAN_OPTIONSUmgebungsvariable in der Entwickler-Eingabeaufforderung wie folgt festlegen:set ASAN_OPTIONS=continue_on_error=1 - Führen Sie den Testcode mit:
doublefree.exe
Die Ausgabe zeigt, dass ein doppelter kostenloser Fehler aufgetreten ist, und der Aufrufstapel, in dem er aufgetreten ist. Der Bericht beginnt mit einem Aufrufstapel, in dem der Fehler aufgetreten ist BadFunction:
==22976==ERROR: AddressSanitizer: attempting double-free on 0x01e03550 in thread T0:
#0 free D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp(69)
#1 BadFunction C:\Users\xxx\Desktop\COE\doublefree.cpp(8)
#2 main C:\Users\xxx\Desktop\COE\doublefree.cpp(14)
#3 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
#4 BaseThreadInitThunk Windows
#5 RtlInitializeExceptionChain Windows
Als Nächstes gibt es Informationen über den freigegebenen Speicher und einen Aufrufstapel für die Zuordnung des Speichers:
0x01e03550 is located 0 bytes inside of 4-byte region [0x01e03550,0x01e03554)
freed by thread T0 here:
#0 free D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp(69)
#1 BadFunction C:\Users\xxx\Desktop\COE\doublefree.cpp(7)
#2 main C:\Users\xxx\Desktop\COE\doublefree.cpp(14)
#3 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
#4 BaseThreadInitThunk Windows
#5 RtlInitializeExceptionChain Windows
previously allocated by thread T0 here:
#0 malloc D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp(85)
#1 main C:\Users\xxx\Desktop\COE\doublefree.cpp(13)
#2 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
#3 BaseThreadInitThunk Windows
#4 RtlInitializeExceptionChain Windows
Dann gibt es Informationen zum Heap-use-after-free-Fehler. Dies bezieht sich auf die *pointer Verwendung printf() im Aufruf, da der Speicher pointer zuvor freigegeben wurde. Der Aufrufstapel, in dem der Fehler auftritt, wird aufgeführt, ebenso wie die Aufrufstapel, in denen dieser Speicher zugewiesen und freigegeben wurde:
==35680==ERROR: AddressSanitizer: heap-use-after-free on address 0x02a03550 at pc 0x00e91097 bp 0x012ffc64 sp 0x012ffc58READ of size 4 at 0x02a03550 thread T0
#0 main C:\Users\xxx\Desktop\Projects\ASAN\doublefree.cpp(18)
#1 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
#2 BaseThreadInitThunk Windows
#3 RtlInitializeExceptionChain Windows
0x02a03550 is located 0 bytes inside of 4-byte region [0x02a03550,0x02a03554)
freed by thread T0 here:
#0 free D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp(69)
#1 BadFunction C:\Users\xxx\Desktop\Projects\ASAN\doublefree.cpp(7)
#2 main C:\Users\xxx\Desktop\Projects\ASAN\doublefree.cpp(14)
#3 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
#4 BaseThreadInitThunk Windows
#5 RtlInitializeExceptionChain Windows
previously allocated by thread T0 here:
#0 malloc D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp(85)
#1 main C:\Users\xxx\Desktop\Projects\ASAN\doublefree.cpp(13)
#2 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
#3 BaseThreadInitThunk Windows
#4 RtlInitializeExceptionChain Windows
Als Nächstes gibt es Informationen zu den Schattenbytes in der Nähe des Pufferüberlaufs. Weitere Informationen zu Schattenbytes finden Sie unter AddressSanitizer-Schattenbytes.
Nach den Schattenbyteinformationen wird die Ausgabe des Programms angezeigt, die angibt, dass sie fortgesetzt wird, nachdem ASAN den Fehler erkannt hat:
******* Pointer value: xxx
Anschließend gibt es eine Zusammenfassung der Quelldateien, in denen der Speicherfehler aufgetreten ist. Sie wird nach den eindeutigen Aufrufstapeln für die Speicherfehler in dieser Datei sortiert. Ein eindeutiger Aufrufstapel wird durch den Fehlertyp und den Aufrufstapel bestimmt, in dem der Fehler aufgetreten ist.
Bei dieser Sortierung werden Speichersicherheitsprobleme priorisiert, die möglicherweise am wichtigsten sind. Beispielsweise sind fünf eindeutige Aufrufstapel, die zu unterschiedlichen Speichersicherheitsfehlern in derselben Datei führen, potenziell beunruhigender als ein Fehler, der viele Male erreicht wird. Die Zusammenfassung sieht wie folgt aus:
=== Files in priority order ===
File: D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp Unique call stacks: 1
File: C:\Users\xxx\Desktop\COE\doublefree.cpp Unique call stacks: 1
Schließlich enthält der Bericht eine Zusammenfassung darüber, wo die Speicherfehler aufgetreten sind:
=== Source Code Details: Unique errors caught at instruction offset from source line number, in functions, in the same file. ===
File: D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp
Func: free()
Line: 69 Unique call stacks (paths) leading to error at line 69 : 1
Bug: double-free at instr 19 bytes from start of line
File: C:\Users\xxx\Desktop\COE\doublefree.cpp
Func: main()
Line: 18 Unique call stacks (paths) leading to error at line 18 : 1
Bug: heap-use-after-free at instr 55 bytes from start of line
>>>Total: 2 Unique Memory Safety Issues (based on call stacks not source position) <<<
#0 C:\Users\xxx\Desktop\COE\doublefree.cpp Function: main(Line:18)
Raw HitCnt: 1 On Reference: 4-byte-read-heap-use-after-free
#1 D:\a\_work\1\s\src\vctools\asan\llvm\compiler-rt\lib\asan\asan_malloc_win_thunk.cpp Function: free(Line:69)
Raw HitCnt: 1
In diesem Beispiel erstellen Sie einen Build mit ASAN, der aktiviert ist, um zu testen, was passiert, wenn eine App auf den Speicher zugreift, der nicht gebunden ist. ASAN erkennt diesen Fehler und meldet eine Zusammenfassung der Fehler beim stdout Beenden des Programms.
Erstellen Sie das Beispiel:
Öffnen Sie eine Entwickler-Eingabeaufforderung: Öffnen Sie das Startmenü , geben Sie "Entwicklertools" ein, und wählen Sie in der Liste der Übereinstimmungen die neueste Eingabeaufforderung wie die Entwickler-Eingabeaufforderung für VS 2022 aus.
Erstellen Sie ein Verzeichnis auf Ihrem Computer, um dieses Beispiel auszuführen. Beispiel:
%USERPROFILE%\Desktop\COE.Erstellen Sie in diesem Verzeichnis beispielsweise eine Quelldatei,
coe.cppund fügen Sie den folgenden Code ein:C++#include <stdlib.h> char* func(char* buf, size_t sz) { char* local = (char*)malloc(sz); for (auto ii = 0; ii <= sz; ii++) // bad loop exit test { local[ii] = ~buf[ii]; // Two memory safety errors } return local; } char buffer[10] = {0,1,2,3,4,5,6,7,8,9}; int main() { char* inverted_buf= func(buffer, 10); }
Im vorherigen Code ist der Parameter sz 10, und der ursprüngliche Puffer beträgt 10 Byte. Es gibt zwei Speichersicherheitsfehler:
- eine out-of-bounds load from
bufin theforloop - einen außerhalb der Schleife gespeicherten
localSpeicher in derforSchleife
Der Pufferüberlauf ist auf den Schleifenausgangstest <=szzurückzuführen. Wenn dieses Beispiel ausgeführt wird, ist es zufällig sicher. Dies liegt daran, dass die meisten C++-Laufzeitimplementierungen überlastet und ausgerichtet sind. Wenn sz % 16 == 0der letzte Schreibvorgang zum local[ii] Beschädigten Arbeitsspeicher verwendet wird. Andere Fälle verwenden nur Lese-/Schreibzugriff auf den "malloc slop", was aufgrund der Art und Weise, wie die C-Runtime-Pads (CRT)-Zuweisungen an eine Grenze von 0 mod 16 zugeordnet sind, zusätzlichen Arbeitsspeicher zugewiesen ist.
Fehler können nur beobachtet werden, wenn die Seite nach der Zuordnung nicht zugeordnet ist oder beschädigte Daten verwendet werden. Alle anderen Fälle werden in diesem Beispiel automatisch ausgeführt. Bei "Weiter beim Fehler" werden die Fehler in der Zusammenfassung angezeigt, nachdem das Programm abgeschlossen wurde.
Erstellen Sie einen Build des vorherigen Codes, bei dem COE aktiviert ist:
- Kompilieren des Codes mit
cl -fsanitize=address -Zi coe.cpp. Der-fsanitize=addressSchalter aktiviert ASAN und-Zierstellt eine separate PDB-Datei, die zum Anzeigen von Informationen zum Speicherfehlerspeicherort verwendet wird. - Senden Sie die ASAN-Ausgabe,
stdoutindem Sie dieASAN_OPTIONSUmgebungsvariable in der Entwickler-Eingabeaufforderung wie folgt festlegen:set ASAN_OPTIONS=continue_on_error=1 - Führen Sie den Testcode mit:
coe.exe
Die Ausgabe zeigt, dass zwei Speicherpufferüberlauffehler aufgetreten sind, und stellt den Aufrufstapel für den Ort bereit, an dem sie aufgetreten sind. Der Bericht beginnt wie folgt:
==9776==ERROR: AddressSanitizer: global-buffer-overflow on address 0x0047b08a at pc 0x003c121b bp 0x012ffaec sp 0x012ffae0
READ of size 1 at 0x0047b08a thread T0
#0 func C:\Users\xxx\Desktop\COE\coe.cpp(8)
#1 main C:\Users\xxx\Desktop\COE\coe.cpp(18)
#2 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
#3 BaseThreadInitThunk Windows
#4 RtlInitializeExceptionChain Windows
Als Nächstes gibt es Informationen zu den Schattenbytes in der Nähe des Pufferüberlaufs. Weitere Informationen zu Schattenbytes finden Sie unter AddressSanitizer-Schattenbytes.
Nach dem Schattenbytebericht gibt es eine Zusammenfassung der Quelldateien, in denen die Speicherfehler aufgetreten sind. Sie wird nach den eindeutigen Aufrufstapeln für die Speicherfehler in dieser Datei sortiert. Ein eindeutiger Aufrufstapel wird durch den Fehlertyp und den Aufrufstapel bestimmt, in dem der Fehler aufgetreten ist.
Bei dieser Sortierung werden Speichersicherheitsprobleme priorisiert, die möglicherweise am wichtigsten sind. Beispielsweise sind fünf eindeutige Aufrufstapel, die zu unterschiedlichen Speichersicherheitsfehlern in derselben Datei führen, potenziell beunruhigender als ein Fehler, der viele Male erreicht wird.
Die Zusammenfassung sieht wie folgt aus:
=== Files in priority order ===
File: C:\Users\xxx\Desktop\COE\coe.cpp Unique call stacks: 2
Schließlich enthält der Bericht eine Zusammenfassung darüber, wo die Speicherfehler aufgetreten sind. Continue On Error meldet zwei unterschiedliche Fehler, die in derselben Quellzeile auftreten. Der erste Fehler liest Den Speicher an einer globalen Adresse im .data Abschnitt und die anderen Schreibvorgänge in den Vom Heap zugewiesenen Speicher.
Der Bericht sieht wie folgt aus:
=== Source Code Details: Unique errors caught at instruction offset from source line number, in functions, in the same file. ===
File: C:\Users\xxx\Desktop\COE\coe.cpp
Func: func()
Line: 8 Unique call stacks (paths) leading to error at line 8 : 2
Bug: heap-buffer-overflow at instr 124 bytes from start of line
>>>Total: 2 Unique Memory Safety Issues (based on call stacks not source position) <<<
#0 C:\Users\xxx\Desktop\COE\coe.cpp Function: func(Line:8)
Raw HitCnt: 1 On Reference: 1-byte-read-global-buffer-overflow
#1 C:\Users\xxx\Desktop\COE\coe.cpp Function: func(Line:8)
Raw HitCnt: 1 On Reference: 1-byte-write-heap-buffer-overflow
Das Standardmäßige Verhalten der Adressbereinigungs-Laufzeit beendet die App, nachdem der erste gefundene Fehler gemeldet wurde. Die Ausführung der "fehlerhaften" Computeranweisung ist nicht zulässig. Die neue Address Sanitizer-Laufzeit diagnoset und meldet Fehler, führt dann aber nachfolgende Anweisungen aus.
COE versucht, die Steuerung automatisch zurück an die Anwendung zurückzugeben, nachdem jeder Speichersicherheitsfehler gemeldet wurde. Es gibt Situationen, in denen dies nicht möglich ist, z. B. wenn eine Arbeitsspeicherzugriffsverletzung (AV) oder eine fehlerhafte Speicherzuweisung vorliegt. COE wird nach Zugriffsverletzungen nicht fortgesetzt, dass die strukturierte Ausnahmebehandlung des Programms nicht erfasst wird. Wenn COE die Ausführung nicht an die App zurückgeben kann, wird eine CONTINUE CANCELLED - Deadly Signal. Shutting down. Meldung ausgegeben.
Verwenden Sie die Umgebungsvariable ASAN_OPTIONS , um zu bestimmen, wo ASAN-Ausgabe wie folgt gesendet werden soll:
- Ausgabe in Stdout:
set ASAN_OPTIONS=continue_on_error=1 - Ausgabe an stderr:
set ASAN_OPTIONS=continue_on_error=2 - Ausgabe in eine Protokolldatei Ihrer Wahl:
set COE_LOG_FILE=yourfile.log
Die ASAN-Laufzeit imitiert nicht alle nicht definierten Verhaltensweisen der C- und C++-Zuordnungs-/Deallocation-Funktionen. Das folgende Beispiel veranschaulicht, wie sich die ASAN-Version von _alloca von der C-Laufzeitversion unterscheidet:
#include <cstdio>
#include <cstring>
#include <malloc.h>
#include <excpt.h>
#include <windows.h>
#define RET_FINISH 0
#define RET_STACK_EXCEPTION 1
#define RET_OTHER_EXCEPTION 2
int foo_redundant(unsigned long arg_var)
{
char *a;
int ret = -1;
__try
{
if ((arg_var+3) > arg_var)
{
// Call to _alloca using parameter from main
a = (char *) _alloca(arg_var);
memset(a, 0, 10);
}
ret = RET_FINISH;
}
__except(1)
{
ret = RET_OTHER_EXCEPTION;
int i = GetExceptionCode();
if (i == EXCEPTION_STACK_OVERFLOW)
{
ret = RET_STACK_EXCEPTION;
}
}
return ret;
}
int main()
{
int cnt = 0;
if (foo_redundant(0xfffffff0) == RET_STACK_EXCEPTION)
{
cnt++;
}
if (cnt == 1)
{
printf("pass\n");
}
else
{
printf("fail\n");
}
}
In main() einer großen Zahl wird an , foo_redundantdie letztendlich übergeben _alloca()wird, was zu einem Fehler führt _alloca() .
In diesem Beispiel wird pass bei der Kompilierung ohne ASAN (d. s. kein -fsanitize=address Schalter) ausgegeben, aber beim Kompilieren mit aktivierter ASAN-Funktion (d. a. mit dem fail Schalter) ausgegeben-fsanitize=address. Das liegt daran, dass der Ausnahmecode RET_STACK_EXCEPTIONcnt ohne ASAN auf 1 festgelegt ist. Sie verhält sich anders, wenn sie mit ASAN kompiliert wird, da die ausgelöste Ausnahme stattdessen ein Adressbereinigungsfehler ist: dynamic-stack-buffer-overflow. Das bedeutet, dass der Code RET_OTHER_EXCEPTION nicht RET_STACK_EXCEPTIONcnt auf 1 festgelegt ist.
Mit der neuen ASAN-Laufzeit müssen keine zusätzlichen Binärdateien mit Ihrer App bereitgestellt werden. Dies erleichtert die Verwendung von ASAN mit Ihrer normalen Testumgebung, da Sie keine zusätzlichen Binärdateien verwalten müssen.
AddressSanitizer Continue on Error Blogbeitrag
Beispiel für Speichersicherheitsfehler
-Zi-Compilerflagge
-fsanitize=address compiler flag
Die 25 gefährlichsten Softwareschwächen