Page History

Dynamic memory managers are not required to clear freed memory and generally do not because of the additional runtime overhead.  Furthermore, dynamic memory managers are free to reallocate this same memory.  As a result, it is possible to accidently leak sensitive information if it is not cleared before calling a function which frees, or may free, dynamic memory.  An example of this risk is the "Sun tarball" vulnerability described in \[Graff 03\].  Programmers cannot rely on memory being cleared during allocation either \[[MEM33-C|MEM33-C. Do not assume memory allocation routines initialize memory]\].

Using {{realloc()}} to resize dynamic memory may inadvertently expose sensitive information, or allow heap inspection as is described in Fortify's Taxonomy of Software Security Errors \[[vulncat|http://vulncat.fortifysoftware.com/2/HI.html]\] and NIST's Source Code Analysis Tool Functional Specification \[[SAMATENIST 06b|http://samate.nist.gov/docs/SAMATE_source_code_analysis_tool_spec_09_15_06.pdf]\]. When {{realloc()}} is called it may allocate a new, larger object, copy the contents, of {{secret}} to this new object, {{free()}} the original object, and assign the newly allocated object to {{secret}}. However, the contents of the original object may remain in memory.