Im Anschluss an die DiskussionHierWenn Sie eine sichere Klasse zum Speichern vertraulicher Informationen (z. B. Kennwörter) im Speicher haben möchten, müssen Sie:

Löschen Sie den Speicher, bevor Sie ihn freigebenNeuzuordnungen müssen ebenfalls der gleichen Regel folgen - anstatt realloc zu verwenden, müssen Sie malloc verwenden, um einen neuen Speicherbereich zu erstellen, den alten in den neuen zu kopieren und dann den alten Speicher zu speichern / löschen, bevor Sie ihn endgültig freigeben

Das hört sich gut an und ich habe eine Testklasse erstellt, um zu sehen, ob das funktioniert. Also habe ich einen einfachen Testfall gemacht, in dem ich die Wörter "LOL" und "WUT", gefolgt von einer Zahl, ungefähr tausend Mal zu dieser sicheren Pufferklasse hinzufüge, um dieses Objekt zu zerstören, bevor ich schließlich etwas tue, das einen Core Dump verursacht.

Da die Klasse den Speicher vor der Zerstörung sicher löschen soll, darf ich keine "LOLWUT" auf dem Coredump finden. Ich konnte sie jedoch immer noch finden und fragte mich, ob meine Implementierung nur fehlerhaft ist. Ich habe jedoch dasselbe mit dem SecByteBlock der CryptoPP-Bibliothek versucht:

#include <cryptopp/osrng.h>
#include <cryptopp/dh.h>
#include <cryptopp/sha.h>
#include <cryptopp/aes.h>
#include <cryptopp/modes.h>
#include <cryptopp/filters.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
using namespace std;

int main(){
   {
      CryptoPP::SecByteBlock moo;

      int i;
      for(i = 0; i < 234; i++){
         moo += (CryptoPP::SecByteBlock((byte*)"LOL", 3));
         moo += (CryptoPP::SecByteBlock((byte*)"WUT", 3));

         char buffer[33];
         sprintf(buffer, "%d", i);
         string thenumber (buffer);

         moo += (CryptoPP::SecByteBlock((byte*)thenumber.c_str(), thenumber.size()));
      }

      moo.CleanNew(0);

   }

   sleep(1);

   *((int*)NULL) = 1;

   return 0;
}

Und dann kompilieren mit:

g++ clearer.cpp -lcryptopp -O0

Und aktivieren Sie dann Core Dump

ulimit -c 99999999

Aber dann Core Dump aktivieren und ausführen

./a.out ; grep LOLWUT core ; echo hello

gibt die folgende Ausgabe aus

Segmentation fault (core dumped)
Binary file core matches
hello

Was verursacht das? Wurde der gesamte Speicherbereich für die Anwendung aufgrund der durch das Anhängen von SecByteBlock verursachten Neuzuordnung neu zugeordnet?

Ebenfalls,Dies ist die Dokumentation von SecByteBlock

bearbeiten: Nachdem ich den Core-Dump mit vim überprüft habe, habe ich Folgendes erhalten:http://imgur.com/owkaw

edit2: aktualisierter Code, damit er leichter kompilierbar ist, und Kompilierungsanweisungen

final edit3: Es sieht so aus, als ob memcpy der Schuldige ist. Siehe Rasmus 'mymemcpy Umsetzung auf seine Antwort unten.