Re: Suggestion of Repositioning CWE #244

On Thu, 3 Jul 2008, koo wrote:

> We suggest that CWE #244, Failure to Clear Heap Memory Before Release, also
> be a child of CWE #226, Sensitive Information Uncleared Before Release.
> #244 is just the specific case of (mis)using realloc() for sensitive
> information.

This makes sense.  Pending further commentary from the researcher list, we
will do this.

> They are both children of CWE #633, Weaknesses that Affect Memory, but
> don't have any other connection in the CWE that we can see.

This is a good example of the kind of "cleanup" and mapping task that we
are hoping to partially address with improved mapping guidance and
organizational views such as the natural hierarchy.  We hope that the
natural hierarchy would provide a mechanism for more easily finding these
relationships.

> For that matter we suggest #244 NOT be a child of #404, Improper Resource
> Shutdown or Release.  #404 is about freeing what you allocate, unlocking
> what you lock, etc. - it can lead to memory leak or resource leak.

We intend for 404 to be a pretty high-level entry that covers any
situation in which the developer does not properly "get rid of" resources
such as memory, locks, files, processes, and connections.  Note how this
is separable from the *consequences* of those actions, such as information
leaks or resource consumption. It might be good for us to modify 404 to
better emphasize how we view it.

> #244 talks about sensitive information being exposed because it is not
> erased from a resource before being released.

Here, #244 suffers a little bit from a perspective problem.
Specifically, it is currently written to emphasize the information leak,
instead of the root cause of using memory allocation routines that might
release memory back to the OS in an uncontrolled fashion.

So, the descriptive text for 244 would need to be modified a bit to "fix"
the perspective to focus more on the weakness.

Now, about the relationships between 226, 244, and 404.

As you observed, 226 and 244 don't share any parents besides CWE-633,
Weaknesses that Affect Memory.  226 is currently classified under CWE-200,
Information Leak.  But "information leak" is usually a consequence (i.e.,
resultant) - so it's typically the final link of a chain.  While we
currently say that 226 is a ChildOf information leak, it would be better
represented as a CanPrecede relationship.

We then face the question of where 226 fits under the natural hierarchy,
since neither of its two parents are "natural parents:" 630 is actually a
view, and 200 is a chaining relationship, not a parent/child relationship.

We still think that 244 belongs somewhere under 404, probably as a
grandchild through its ChildOf relationship with 226 (i.e. 244 as a
ChildOf 226, and 226 as a ChildOf 404).  404 itself is a child of 664,
Insufficient Control of a Resource Through its Lifetime, which we view as
a likely "pillar" (top-level node) of the natural hierarchy.

There is another perspective issue to consider.  Some might argue that
244, which is specifically about using realloc() to resize buffers, should
fall under CWE-227, API Abuse.  This is how it was categorized in Seven
Pernicious Kingdoms, for example.  CWE 1.0 will support a Seven Pernicious
Kingroms view (CWE-700, specifically) that will preserve this
relationship.  However, we are also trying to figure out how to clearly
define CWE-227 in a way that doesn't effectively include everything that's
a weakness - after all, writing code that allows writing outside of a
memory buffer could distincly be counted as "API abuse" as well.  We think
that CWE-227 has a place in the natural hierarchy, but that means that 244
would have multiple natural parents.  Currently, we are allowing this to
happen - so "hierarchy" is currently a misnomer.

I hope this addresses your questions and helps to illuminate some of the
issues we face leading up to CWE 1.0.

- Steve