Po dyskusjitutaj, jeśli chcesz mieć bezpieczną klasę do przechowywania poufnych informacji (np. haseł) w pamięci, musisz:

memset / wyczyść pamięć przed zwolnieniemreallocations muszą również spełniać tę samą regułę - zamiast używać realloc, użyj malloc, aby utworzyć nowy region pamięci, skopiuj stary do nowego, a następnie zapisz / wyczyść starą pamięć, zanim w końcu ją zwolnisz

Brzmi to dobrze i stworzyłem klasę testową, aby sprawdzić, czy to działa. Zrobiłem więc prosty przypadek testowy, w którym ciągle dodam słowa „LOL” i „WUT”, po których następuje numer do tej bezpiecznej klasy buforów około tysiąca razy, niszcząc ten obiekt, zanim w końcu zrobię coś, co powoduje zrzut pamięci.

Ponieważ klasa ma bezpiecznie usuwać pamięć przed zniszczeniem, nie powinienem być w stanie znaleźć „LOLWUT” na rdzeniu. Udało mi się je jednak znaleźć i zastanawiałem się, czy moja implementacja jest po prostu błędna. Jednak spróbowałem tego samego za pomocą SecByteBlock biblioteki CryptoPP:

#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;
}

Następnie skompiluj używając:

g++ clearer.cpp -lcryptopp -O0

A następnie włącz zrzut pamięci

ulimit -c 99999999

Ale potem, uruchamiając zrzut pamięci i uruchamiając go

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

daje następujące wyjście

Segmentation fault (core dumped)
Binary file core matches
hello

Co to powoduje? Czy cały obszar pamięci dla aplikacji został ponownie przydzielony z powodu ponownego przydzielenia spowodowanego przez dodatek SecByteBlock?

Również,To jest dokumentacja SecByteBlock

edytować: Po sprawdzeniu zrzutu pamięci przy użyciu vima, mam to:http://imgur.com/owkaw

edytuj2: zaktualizowany kod, dzięki czemu jest łatwiejszy do skompilowania i instrukcje kompilacji

ostatnia edycja3: Wygląda na to, że memcpy jest winowajcą. Zobacz Rasmus 'mymemcpy wdrożenie na jego odpowiedź poniżej.