How-to ensure that compiler optimizations don't introduce a security risk ?

Question

I have to write a Windows service that handles at some point confidential data (such as PIN codes, passwords, and so on). Those informations are needed for a very short amount of time: usually they are sent almost immediately to a smart card reader.

Lets consider this piece of code:

{
  std::string password = getPassword(); // Get the password from the user

  writePasswordToSmartCard(password);

  // Okay, here we don't need password anymore.
  // We set it all to '\0' so it doesn't stay in memory.
  std::fill(password.begin(), password.end(), '\0');
}

Now my concern is about compiler optimizations. Here the compiler might detect that password is about to be deleted and that changing its value at this point is useless and just remove the call.

I don't expect my compiler to care about the value of future-unreferenced memory.

Are my concerns legitimate ? How can I be sure that such a piece of code won't be optimized-out ?

Answer 1

Yes, your concerns are legitimate. You need to use specifically designed function like SecureZeroMemory() to prevent optimizations from modifying your code behavior.

Don't forget that the string class should have been specifically designed for handling passwords. For example, if the class reallocates the buffer to hold a longer string it has to erase the buffer before retunring it to the memory allocator. I'm not sure, but it's likely std::string doesn't do that (at least by default). Using an unsuitable string handling class makes all your concerns worthless - you'll have the password copied all over the program memory befoe you even know.

Answer 2

It's problematic, but for another reason. Who said that std::string password = getPassword(); doesn't leave yet another copy in the memory? (Probably you need to write a "secure" allocator class for this that zeros memory on "destruct" or "deallocate")

In your peace of code you can avoid optimization by getting a volatile pointer to the string data (I don't know if you can do it in standard way) and then zero the data through.

Answer 3

Declare password volatile to prevent the compiler making any assumptions about removing explicit read or writes.

volatile std::string password = getPassword(); // Get the password from the user

Answer 4

Why dont you just disable optimization for the code in question?

#pragma optimize( "", off )

// Code, not to optimize goes here

#pragma optimize( "", on )

This sample of #pragma optimize is specific to MSVC, but other compilers support it as well.

Answer 5

In this specific instance, I'd be really surprised if the compiler can optimise away a method invocation that could clearly have side effects. Or is std::fill inline so the compiler can see the implementation? (I'm not a C++ programmer).

Having said that, this kind of thing can be a concern generally. But you need to think about how easy it is to exploit. To read the memory of another process, an attacker would need some level of administrator access (if not, why are you using that operating system). If the machine is compromised to that level, you've already lost.

Answer 6

Don't use std::string for passwords, as it doesn't zero out it's memory when doing reallocations or destruction - design your own ConfidentialString class instead. When designing that class, you might want to take advantage of CryptProtectMemory... and be very, very careful when you need to use the decrypted version, especially when calling external code.