Secure Deallocation

While unpacking from my recent office move I came across an old copy of an excellent paper titled "Shredding Your Garbage: Reducing Data Lifetime Through Secure Deallocation" (pdf). Deallocation of sensitive information is something that is critical when developing secure systems, but is often overlooked. The problem is as follows: sensitive information is stored in memory and deallocated without first being overwritten. The memory is now eligible to be reallocated to a different program, but the sensitive data remains present and accessible in memory for an indeterminate period until another program overwrites that address. The problem is compounded when memory is written to disk as part of a swap file. Once sensitive data is written to disk it can remain there and accessible for a very long time.

"Shredding Your Garbage" focuses on increasing general system security by zeroing out memory before deallocation in the general system allocation routines. The authors modified the memory allocation systems of Linux so that memory is automatically overwritten before being freed. They discovered that the performance cost was generally small (on the order of 1% for most tasks).

So, should secure deallocation be implemented at the OS level? Ultimately it is the responsibility of the application developer to zero out any sensitive information in memory as soon as it is no longer needed. That said, implementing secure deallocation at the system level could provide another safeguard and protect against forgetful application developers. Given the relatively small performance cost I think that this could be an interesting and useful feature in operating systems for security critical applications. Of course, I know of no major OS distribution that does this so at this point the debate remains academic.

Most of my day to day work takes place in memory managed languages that run in a VM. A system level secure allocation system would not necessarily would not necessarily help these languages as memory that has been garbage collected is not necessarily freed from the VM to the operating system. Furthermore, Strings in both .Net and Java are immutable. This makes it impossible to effectively zero out strings. So, any information that is placed in a string will have an indefinite lifetime in memory. Therefore, it is critical that developers avoid storing sensitive information (passwords, cryptographic keys, etc) in strings whenever possible. Byte or character arrays are alternatives that allows the information to be zeroed out before becoming eligible for garbage collection. In 2.0 .Net has added SecureString that keep the contents encrypted in memory and securely delete it upon garbage collection.

OS level secure deallocation may in the future help cover for sloppy coders, but for now, always remember to zero any sensitive data from memory as soon as you are done using it.