3 ms·
Additional evidence of inadequate .NET implementation: There is a ton of code & pointless complexity to minimize the time sensitive data has to remain in plain
by sdrapkin 11y ago
Additional evidence of inadequate .NET implementation:
There is a ton of code & pointless complexity to minimize the time sensitive data has to remain in plaintext in memory, and zeroing buffers asap. Clearly, the "process memory compromise" threat vector is taken very seriously by the authors.
Here's a KeePass function that generates a key:
https://github.com/wrouesnel/keepass/blob/master/KeePassLib/Keys/CompositeKey.cs#L155 https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...
Does anyone see what the problem is? Hint: disposing "ms" in addition to closing will not fix the problem.
There are ~ 59 instances of this mistake in the codebase. The author(s) seem to come from c/c++ background, and make all kinds of assumptions about how .NET works - except that .NET doesn't work the way they think it works.
The generation of the Master Key:
https://github.com/wrouesnel/keepass/blob/master/KeePassLib/Keys/CompositeKey.cs#L243 https://github.com/wrouesnel/keepass/blob/master/KeePassLib/...
Note that "pbNewKey" can be sitting in memory forever.
TL/DR: KeePass memory protection is completely ineffective (I only speak for .NET implementation).
- mrsaint 11y agoWould be interesting to compare the .NET implementation to the "legacy" c version, Keepass 1.x. https://github.com/joshuadugie/KeePass-1.x https://github.com/joshuadugie/KeePass-1.x