CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

CWE Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (4.1)  
ID

CWE-244: Improper Clearing of Heap Memory Before Release ('Heap Inspection')

Weakness ID: 244
Abstraction: Variant
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
+ Extended Description
When sensitive data such as a password or an encryption key is not removed from memory, it could be exposed to an attacker using a "heap inspection" attack that reads the sensitive data using memory dumps or other methods. The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.226Sensitive Information Uncleared in Resource Before Release for Reuse
CanPrecedeClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.669Incorrect Resource Transfer Between Spheres
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Confidentiality
Other

Technical Impact: Read Memory; Other

Be careful using vfork() and fork() in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use.
+ Demonstrative Examples

Example 1

The following code calls realloc() on a buffer containing sensitive data:

(bad code)
Example Language:
cleartext_buffer = get_secret();...
cleartext_buffer = realloc(cleartext_buffer, 1024);
...
scrub_memory(cleartext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so a copy of the data can still be exposed in the memory originally allocated for cleartext_buffer.

+ Affected Resources
  • Memory
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.2277PK - API Abuse
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.742CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOfViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).884CWE Cross-section
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.963SFP Secondary Cluster: Exposed Data
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsHeap Inspection
CERT C Secure CodingMEM03-CClear sensitive information stored in reusable resources returned for reuse
Software Fault PatternsSFP23Exposed Data
+ References
[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2006-07-197 Pernicious Kingdoms
+ Modifications
Modification DateModifierOrganization
2008-08-01KDM Analytics
added/updated white box definitions
2008-09-08CWE Content TeamMITRE
updated Applicable_Platforms, Name, Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITRE
updated Relationships
2008-11-24CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Demonstrative_Examples, Name
2009-10-29CWE Content TeamMITRE
updated Common_Consequences, Description, Other_Notes
2010-12-13CWE Content TeamMITRE
updated Name
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2011-09-13CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Relationships
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings, White_Box_Definitions
2020-02-24CWE Content TeamMITRE
updated References, Relationships
+ Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Heap Inspection
2008-09-09Failure to Clear Heap Memory Before Release
2009-05-27Failure to Clear Heap Memory Before Release (aka 'Heap Inspection')
2010-12-13Failure to Clear Heap Memory Before Release ('Heap Inspection')
More information is available — Please select a different filter.
Page Last Updated: June 25, 2020