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).


Jonas
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to