Ja, es ist aus Sicherheitsgründen empfehlenswert, Daten zu überschreiben, die besonders sensibel sind, wenn die Daten nicht mehr benötigt werden, dh als Teil eines Objektdestruktors (entweder ein expliziter Destruktor, der von der Sprache bereitgestellt wird, oder eine Aktion, die das Programm ausführt vor der Freigabe des Objekts). Es ist sogar empfehlenswert, Daten zu überschreiben, die an sich nicht sensibel sind, z. B. Zeigerfelder in einer nicht mehr verwendeten Datenstruktur auf Null zu setzen und Zeiger auf Null zu setzen, wenn das Objekt, auf das sie zeigen, freigegeben wird, selbst wenn Sie es wissen Sie werden dieses Feld nicht mehr verwenden.
Ein Grund dafür ist, dass die Daten durch externe Faktoren wie einen exponierten Core-Dump, ein gestohlenes Ruhezustand-Image oder einen kompromittierten Server, der einen Speicher zulässt, verloren gehen Speicherauszug laufender Prozesse usw. Physische Angriffe, bei denen ein Angreifer die RAM-Sticks extrahiert und Datenreste nutzt, sind selten ein Problem, außer bei Laptops und möglicherweise mobilen Geräten wie Telefonen (bei denen der Balken höher ist, weil der RAM gelötet ist). und selbst dann meistens nur in gezielten Szenarien. Die Remanenz überschriebener Werte ist kein Problem: Es würde sehr teure Hardware erfordern, um in einem RAM-Chip nach einer verbleibenden mikroskopischen Spannungsdifferenz zu suchen, die durch einen überschriebenen Wert beeinflusst werden könnte. Wenn Sie sich Sorgen über physische Angriffe auf den RAM machen, besteht ein größeres Problem darin, sicherzustellen, dass die Daten im RAM und nicht nur im CPU-Cache überschrieben werden. Aber auch dies ist normalerweise ein sehr geringes Problem.
Der wichtigste Grund für das Überschreiben veralteter Daten ist die Abwehr von Programmfehlern, die dazu führen, dass nicht initialisierter Speicher verwendet wird, wie z. B. das berüchtigte Heartbleed. Dies geht über sensible Daten hinaus, da das Risiko nicht auf ein Datenleck beschränkt ist: Wenn ein Softwarefehler vorliegt, der dazu führt, dass ein Zeigerfeld ohne Initialisierung dereferenziert wird, ist der Fehler sowohl weniger anfällig für Ausnutzung als auch leichter zu verfolgen, wenn Das Feld enthält alle Bits-Null, als wenn es möglicherweise auf einen gültigen, aber bedeutungslosen Speicherort verweist.
Beachten Sie, dass gute Compiler das Nullstellen optimieren, wenn sie feststellen, dass der Wert nicht mehr verwendet wird. Möglicherweise müssen Sie einen compilerspezifischen Trick verwenden, um den Compiler davon zu überzeugen, dass der Wert weiterhin verwendet wird, und so den Nullungscode zu generieren.
In vielen Sprachen mit automatischer Verwaltung können Objekte ohne in den Speicher verschoben werden beachten. Dies bedeutet, dass es schwierig ist, Lecks veralteter Daten zu kontrollieren, es sei denn, der Speichermanager selbst löscht nicht verwendeten Speicher (dies ist aus Leistungsgründen häufig nicht der Fall). Auf der positiven Seite sind externe Lecks normalerweise alles, worüber Sie sich Sorgen machen müssen, da Hochsprachen dazu neigen, die Verwendung von nicht initialisiertem Speicher auszuschließen (Vorsicht vor Funktionen zum Erstellen von Zeichenfolgen in Sprachen mit veränderlichen Zeichenfolgen).
By Übrigens habe ich oben „Null raus“ geschrieben. Sie können ein anderes Bitmuster als alle Nullen verwenden. All-Nullen haben den Vorteil, dass sie in den meisten Umgebungen ein ungültiger Zeiger sind. Ein Bitmuster, von dem Sie wissen, dass es ungültige Zeiger sind, das jedoch eindeutiger ist, kann beim Debuggen hilfreich sein.
Viele Sicherheitsstandards schreiben das Löschen vertraulicher Daten wie Schlüssel vor. Zum Beispiel erfordert der FIPS 140-2 -Standard für kryptografische Module dies auch bei der niedrigsten Sicherheitsstufe, was im Übrigen nur die Einhaltung von Funktionen und keine Widerstandsfähigkeit gegen Angriffe erfordert.