Limpando a memória com segurança e realocações
Após a discussãoAqui, se você quiser ter uma classe segura para armazenar informações confidenciais (por exemplo, senhas) na memória, é necessário:
memset / limpe a memória antes de liberá-larealocações também devem seguir a mesma regra - em vez de usar realloc, use malloc para criar uma nova região de memória, copie o antigo para o novo e então memset / limpe a memória antiga antes de liberá-la finalmenteEntão, isso soa bem, e eu criei uma classe de teste para ver se isso funciona. Então eu fiz um teste simples onde eu continuo adicionando as palavras "LOL" e "WUT", seguidas por um número para essa classe de buffer seguro em torno de mil vezes, destruindo aquele objeto, antes de finalmente fazer algo que causa um dump principal.
Como a classe deve limpar com segurança a memória antes da destruição, não devo encontrar um "LOLWUT" no coredump. No entanto, eu ainda consegui encontrá-los, e me perguntei se a minha implementação é apenas buggy. No entanto, eu tentei a mesma coisa usando o SecByteBlock da biblioteca 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;
}
E então compile usando:
g++ clearer.cpp -lcryptopp -O0
E depois ativar o core dump
ulimit -c 99999999
Mas, então, habilitar o core dump e executá-lo
./a.out ; grep LOLWUT core ; echo hello
dá a seguinte saída
Segmentation fault (core dumped)
Binary file core matches
hello
O quê está causando isto? Toda a região de memória para o aplicativo realocou-se, devido à realocação causada pelo acréscimo do SecByteBlock?
Além disso,Esta é a documentação do SecByteBlock
editar: Depois de verificar o core dump usando vim, eu tenho isso:http://imgur.com/owkaw
edit2: código atualizado para que seja mais facilmente compilável e instruções de compilação
edição final3: Parece que memcpy é o culpado. Veja o Rasmus 'mymemcpy
implementação em sua resposta abaixo.