How can I increase memory security in Delphi?

Question

Is it possible to "wipe" strings in Delphi? Let me explain:

I am writing an application that will include a DLL to authorise users. It will read an encrypted file into an XML DOM, use the information there, and then release the DOM.

It is obvious that the unencrypted XML is still sitting in the memory of the DLL, and therefore vulnerable to examination. Now, I'm not going to go overboard in protecting this - the user could create another DLL - but I'd like to take a basic step to preventing user names from sitting in memory for ages. However, I don't think I can easily wipe the memory anyway because of references. If I traverse my DOM (which is a TNativeXML class) and find every string instance and then make it into something like "aaaaa", then will it not actually assign the new string pointer to the DOM reference, and then leave the old string sitting there in memory awaiting re-allocation? Is there a way to be sure I am killing the only and original copy?

Or is there in D2007 a means to tell it to wipe all unused memory from the heap? So I could release the DOM, and then tell it to wipe.

Or should I just get on with my next task and forget this because it is really not worth bothering.

Answer 1

Messy but you could make a note of the heap size that you've used while you've got the heap filled with sensitive data then when that is released do a GetMem to allocate you a large chunk spanning (say) 200% of that. do a Fill on that chunk and make the assumption that any fragmentation is unlinkely to be of much use to an examiner. Bri

Answer 2

How about decrypting the file to a stream, using a SAX processor instead of an XML DOM to do your verification and then overwriting the decrypted stream before freeing it?

Answer 3

How about keeping the password as a hash value in the XML and verify by comparing the hash of the input password with the hashed password in your XML.

Edit: You can keep all the sensitive data encrypted and decrypt only at the last possible moment.

Answer 4

DLLs don't own allocated memory, processes do. The memory allocated by your specific process will be discarded once the process terminates, whether the DLL hangs around (because it is in use by another process) or not.

Answer 5

I don't think it is worth bothering with, because if a user can read the memory of the process using the DLL, the same user can also halt the execution at any given point in time. Halting the execution before the memory is wiped will still give the user full access to the unencrypted data.

IMO any user sufficiently interested and able to do what you describe will not be seriously inconvenienced by your DLL wiping the memory.

Answer 6

Two general points about this:

First, this is one of those areas where "if you have to ask, you probably shouldn't be doing this." And please don't take that the wrong way; I mean no disrespect to your programming skills. It's just that writing secure, cryptographically strong software is something that either you're an expert at or you aren't. Very much in the same way that knowing "a little bit of karate" is much more dangerous than knowing no karate at all. There are a number of third-party tools for writing secure software in Delphi which have expert support available; I would strongly encourage anyone without a deep knowledge of cryptographic services in Windows, the mathematical foundations of cryptography, and experience in defeating side channel attacks to use them instead of attempting to "roll their own."

To answer your specific question: The Windows API has a number of functions which are helpful, such as CryptProtectMemory. However, this will bring a false sense of security if you encrypt your memory, but have a hole elsewhere in the system, or expose a side channel. It can be like putting a lock on your door but leaving the window open.

Answer 7

If you use the FastMM memory manager in Full Debug mode, then you can force it to overwrite memory when it is being freed.

Normally that behaviour is used to detect wild pointers, but it can also be used for what your want.

On the other hand, make sure you understand what Craig Stuntz writes: do not write this authentication and authorization stuff yourself, use the underlying operating system whenever possible.

BTW: Hallvard Vassbotn wrote a nice blog about FastMM: http://hallvards.blogspot.com/2007/05/use-full-fastmm-consider-donating.html

Regards,

Jeroen Pluimers

Answer 8

Would it be possible to load the decrypted XML into an array of char or byte rather than a string? Then there would be no copy-on-write handling, so you would be able to backfill the memory with #0's before freeing?

Be careful if assigning array of char to string, as Delphi has some smart handling here for compatibility with traditional packed array[1..x] of char.

Also, could you use ShortString?

Answer 9

If your using XML, even encrypted, to store passwords your putting your users at risk. A better approach would be to store the hash values of the passwords instead, and then compare the hash against the entered password. The advantage of this approach is that even in knowing the hash value, you won't know the password which makes the hash. Adding a brute force identifier (count invalid password attempts, and lock the account after a certain number) will increase security even further.

There are several methods you can use to create a hash of a string. A good starting point would be to look at the turbo power open source project "LockBox", I believe it has several examples of creating one way hash keys.

EDIT

But how does knowing the hash value if its one way help? If your really paranoid, you can modify the hash value by something prediticable that only you would know... say, a random number using a specific seed value plus the date. You could then store only enough of the hash in your xml so you can use it as a starting point for comparison. The nice thing about psuedo random number generators is that they always generate the same series of "random" numbers given the same seed.

Answer 10

How about something like this?

procedure WipeString(const str: String); var i:Integer; iSize:Integer; pData:PChar;

begin iSize := Length(str); pData := PChar(str);

for i := 0 to 7 do
begin
  ZeroMemory(pData, iSize);
  FillMemory(pData, iSize, $FF); // 1111 1111
  FillMemory(pData, iSize, $AA); // 1010 1010
  FillMemory(pData, iSize, $55); // 0101 0101
  ZeroMemory(pData, iSize);
end;

end;