|the root of the problem is that memory is not 'reset' or 'defaulted' to anything|
Well, I wouldn't count this as the "root of the problem". Actually, resetting memory is just one solution for the real problem ;-) (e.g. using encrypted memory and some hardware key storage is another). For me, the root lies somewhere else.
When you design a security system, you have to make assumptions what an attacker can do and what he can't. (There is no security against an omnipotent, god-like attacker that can read minds, examine all atoms in the world, even break (quantum) physic laws etc..). So in fact, you always have to make assumptions.
When designing hard drive encryption, the designer made the assumption, that RAM can not be read. If you now negate this assumption, the system doesn't provide security anymore. Nothing to be surprised at. So why is this still a "problem" and why are we surprised now? Because the designers may not have been aware of their assumptions. They probably didn't write it clearly on their advertisment: "Warning: This doesn't work if someone owns a $7 bottle of cyrogenics."
So the root of the problem lies in the fact, that the designer didn't thought of all assumptions they made and that their attacker model just descirbed the wrong attacker (more specific: a too weak attacker).
|is there a conceivable way to write a program to manually (at your choosing), 'scrub' the memory?|
I guess its just better if you enable things like "Forget password at ScreenSaver-lock" in TrueCrypt. For linux and dm-crypt, you probably would have to write some suspend-script. IDK how and where, ask in their forums ;-).
You can also use GnuPG in -c mode (symmetric on-the-fly encryption/decryption). IIRC, it erease the memory after usage.
Hey, we found a nice circle back to the original topic, but on a different layer: Now we are at "How to erase sensitive information in the RAM?" :-D