安全清除内存并重新分配

Question

在here 的讨论之后，如果你想有一个安全类用于在内存中存储敏感信息（例如密码），你必须：

• memset/clear the memory before free it
• 重新分配也必须遵循相同的规则 - 而不是使用 realloc，而是使用 malloc 创建一个新的内存区域，将旧内存复制到新内存，然后在最终释放之前 memset/clear 旧内存

所以这听起来不错，我创建了一个测试类来看看它是否有效。所以我做了一个简单的测试用例，我不断添加单词“LOL”和“WUT”，然后在这个安全缓冲区类中添加一个数字大约一千次，销毁该对象，然后最终执行导致核心转储的操作。

由于该类应该在销毁之前安全地清除内存，因此我不应该能够在 coredump 上找到“LOLWUT”。但是，我还是设法找到了它们，并想知道我的实现是否只是错误。但是，我使用 CryptoPP 库的 SecByteBlock 尝试了同样的事情：

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

然后编译使用：

g++ clearer.cpp -lcryptopp -O0

然后启用核心转储

ulimit -c 99999999

然后，启用核心转储并运行它

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

给出以下输出

Segmentation fault (core dumped)
Binary file core matches
hello

这是什么原因造成的？由于 SecByteBlock 的 append 引起的重新分配，应用程序的整个内存区域是否重新分配？

另外，This is SecByteBlock's Documentation

edit：使用 vim 检查核心转储后，我得到了这个： http://imgur.com/owkaw

edit2：更新了代码，使其更易于编译，以及编译说明

final edit3：看起来 memcpy 是罪魁祸首。请参阅 Rasmus 的mymemcpy 实现，了解他的回答。

Answer 1

字符串文字将存储在内存中，不由 SecByteBlock 类管理。

this other SO question很好地解释了它： Is a string literal in c++ created in static memory?

您可以通过查看获得的匹配数来尝试确认 grep 匹配是否可以由字符串文字解释。您还可以打印出 SecByteBlock 缓冲区的内存位置，并尝试查看它们是否与核心转储中与您的标记匹配的位置相对应。

Answer 2

这是另一个更直接地重现问题的程序：

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

inline void SecureWipeBuffer(char* buf, size_t n){
  volatile char* p = buf;
  asm volatile("rep stosb" : "+c"(n), "+D"(p) : "a"(0) : "memory");
}

void mymemcpy(char* b, const char* a, size_t n){
  char* s1 = b;
  const char* s2= a;
  for(; 0<n; --n) *s1++ = *s2++;
}

int main(){
  const size_t size1 = 200;
  const size_t size2 = 400;

  char* b = new char[size1];
  for(int j=0;j<size1-10;j+=10){
    memcpy(b+j, "LOL", 3);
    memcpy(b+j+3, "WUT", 3);
    sprintf((char*) (b+j+6), "%d", j);
  }
  char* nb = new char[size2];
  memcpy(nb, b, size1);
  //mymemcpy(nb, b, size1);
  SecureWipeBuffer(b,size1);
  SecureWipeBuffer(nb,size2);

  *((int*)NULL) = 1;

  return 0;    
}

如果您将 memcpy 替换为 mymemcpy 或使用更小的尺寸，问题就会消失，所以我最好的猜测是内置 memcpy 做了一些事情，将部分复制的数据留在内存中。

我想这只是表明从内存中清除敏感数据实际上是不可能的，除非它是从头开始设计到整个系统中的。

Answer 3

如果不检查memcpy_s 的详细信息，我怀疑您看到的是memcpy_s 用于复制小内存缓冲区的临时堆栈缓冲区。您可以通过在调试器中运行并查看查看堆栈内存时是否出现LOLWUT 来验证这一点。

[Crypto++ 中reallocate 的实现在调整内存分配大小时使用memcpy_s，这就是为什么您可以在内存中找到一些LOLWUT 字符串的原因。此外，许多不同的LOLWUT 字符串在该转储中重叠的事实表明它是一个正在被重用的临时缓冲区。]

memcpy 的自定义版本只是一个简单的循环，不需要计数器之外的临时存储，因此这肯定比实现memcpy_s 的方式更安全。

Answer 4

我建议这样做的方法是加密内存中的数据。这样，无论数据是否仍在内存中，数据始终是安全的。当然，缺点是每次访问数据时都需要对数据进行加密/解密。

Answer 5

尽管出现在核心转储中，但密码实际上并不在内存中 清除缓冲区后不再。问题是memcpying a 足够长的字符串会将密码泄漏到 SSE 寄存器中，那些 是核心转储中显示的内容。

当memcpy 的size 参数大于某个特定值时 阈值—80 bytes on the mac—然后使用 SSE 指令执行 内存复制。这些指令更快，因为它们可以复制 16 一次并行处理字节，而不是逐个字符， 一个字节一个字节，或者一个字一个字。这是源代码的关键部分 Libc on the mac:

LAlignedLoop:               // loop over 64-byte chunks
    movdqa  (%rsi,%rcx),%xmm0
    movdqa  16(%rsi,%rcx),%xmm1
    movdqa  32(%rsi,%rcx),%xmm2
    movdqa  48(%rsi,%rcx),%xmm3

    movdqa  %xmm0,(%rdi,%rcx)
    movdqa  %xmm1,16(%rdi,%rcx)
    movdqa  %xmm2,32(%rdi,%rcx)
    movdqa  %xmm3,48(%rdi,%rcx)

    addq    $64,%rcx
    jnz     LAlignedLoop

    jmp     LShort                  // copy remaining 0..63 bytes and done

%rcx是循环索引寄存器，%rsi是s源地址寄存器， %rdi 是 destination 地址寄存器。每次绕圈跑， 64 字节从源缓冲区复制到 4 个 16 字节 SSE 寄存器 xmm{0,1,2,3};然后将这些寄存器中的值复制到 目标缓冲区。

该源文件中还有很多东西可以确保出现副本 仅在对齐的地址上，以填写剩余的副本部分 在完成 64 字节块之后，并处理源和 目的地重叠。

但是——SSE 寄存器在使用后不会被清除！这意味着 64 字节 被复制的缓冲区仍然存在于xmm{0,1,2,3} 寄存器中。

这是对 Rasmus 程序的修改，显示了这一点：

#include <ctype.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <emmintrin.h>

inline void SecureWipeBuffer(char* buf, size_t n){
  volatile char* p = buf;
  asm volatile("rep stosb" : "+c"(n), "+D"(p) : "a"(0) : "memory");
}

int main(){
  const size_t size1 = 200;
  const size_t size2 = 400;

  char* b = new char[size1];
  for(int j=0;j<size1-10;j+=10){
    memcpy(b+j, "LOL", 3);
    memcpy(b+j+3, "WUT", 3);
    sprintf((char*) (b+j+6), "%d", j);
  }
  char* nb = new char[size2];
  memcpy(nb, b, size1);
  SecureWipeBuffer(b,size1);
  SecureWipeBuffer(nb,size2);

  /* Password is now in SSE registers used by memcpy() */
  union {
    __m128i a[4];
    char c;
  };
  asm ("MOVDQA %%xmm0, %0": "=x"(a[0]));
  asm ("MOVDQA %%xmm1, %0": "=x"(a[1]));
  asm ("MOVDQA %%xmm2, %0": "=x"(a[2]));
  asm ("MOVDQA %%xmm3, %0": "=x"(a[3]));
  for (int i = 0; i < 64; i++) {
      char p = *(&c + i);
      if (isprint(p)) {
        putchar(p);
      } else {
          printf("\\%x", p);
      }
  }
  putchar('\n');

  return 0;
}

在我的 Mac 上，打印出来的是：

0\0LOLWUT130\0LOLWUT140\0LOLWUT150\0LOLWUT160\0LOLWUT170\0LOLWUT180\0\0\0

现在，检查核心转储，密码只出现一次， 和确切的0\0LOLWUT130\0...180\0\0\0 字符串一样。核心转储必须 包含所有寄存器的副本，这就是该字符串存在的原因——它是 xmm{0,1,2,4} 寄存器的值。

所以 调用后密码实际上不再在 RAM 中了 SecureWipeBuffer，它似乎只是，因为它实际上在某些 仅出现在核心转储中的寄存器。如果你担心 memcpy 存在可被 RAM 冻结利用的漏洞， 不用担心了。如果在寄存器中保存密码副本让您感到困扰， 使用修改后的memcpy，不使用 SSE2 寄存器，或清除它们 完成后。如果您真的对此感到偏执，请继续测试您的 coredumps 以确保编译器不会优化您的 密码清除代码。