[fpc-pascal] Processing passwords etc.

Jonas Maebe jonas.maebe at elis.ugent.be
Fri Apr 11 10:23:28 CEST 2014

On 11 Apr 2014, at 10:10, Mark Morgan Lloyd wrote:

> Jonas Maebe wrote:
>> On 11 Apr 2014, at 09:36, Mark Morgan Lloyd wrote:
>>> Is my understanding correct that when a string or a dynamic array is extended it might result in its existing content being released to the heap?
>>> If so, is it possible to ensure that this is zeroed or randomised first, without having to do it manually?
>> You can install a memory manager that does this for all (de)allocations and then calls through to the original memory manager. There is no way to only do this for strings and dynamic arrays, and I don't think it would be a good idea to do so. Not all passwords are strings, so that would probably mostly give a false sense of security.
> Using a memory manager would reliably wipe strings etc. when reallocated (i.e rather than when an assignment didn't trigger reallocation). On the other hand it would have the overhead of also overwriting blocks that the user knew were being freed and could audit first, as well as stuff that was being freed as part of the RTL operation.

Such stuff from RTL operations may include getmem'd buffers used to read private key data from disk.

> It's that latter case- where the RTL is copying something without the user being aware- that I think is significant.

Either the memory manager guarantees trashing, or it does not. Having half-solutions are worse than nothing at all, because it gives a false sense of security. Even the best audits are guaranteed to miss things (as in case of the person who wrote and the person who reviewed/audited the patch that introduced the heartbleed bug), and as you mentioned there is no control over the internals of the RTL (which has not been written at all from the point of view that buffers that might sometimes contain sensitive data should always be cleansed).


More information about the fpc-pascal mailing list