Suggestion of Repositioning CWE #244

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestion of Repositioning CWE #244

Michael Koo

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.

 

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.

 

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.  #244 talks about sensitive information being exposed because it is not erased from a resource before being released.

 

For your convenience, here are the URLs and descriptions

    http://cwe.mitre.org/data/definitions/244.html

      Using realloc() to resize buffers that store sensitive

      information can leave the sensitive information exposed to

      attack, because it is not removed from memory.

    http://cwe.mitre.org/data/definitions/226.html

      The software does not fully clear previously used information in

      a data structure, file, or other resource, before making that

      resource available to a party in another control sphere.

    http://cwe.mitre.org/data/definitions/404.html

      The program fails to release - or incorrectly releases - a

      system resource before it is made available for re-use.

 

 

Michael Koo

on Behalf of SAMATE Team

Reply | Threaded
Open this post in threaded view
|

Re: Suggestion of Repositioning CWE #244

ljknews
At 3:08 PM -0400 7/3/08, koo wrote:

> We suggest that CWE #244, Failure to Clear Heap Memory Before Release,

It seems to me that it would be sufficient for the operating
system to clear the memory before reallocation to a process.
Why be concerned about the state when no process can access
it ?

Is there a separate item for clearing stack memory ?  That
would seem vulnerable in the same ways.
--
Larry Kilgallen
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion of Repositioning CWE #244

Pascal Meunier-2-3
ljknews wrote:
> At 3:08 PM -0400 7/3/08, koo wrote:
>
>> We suggest that CWE #244, Failure to Clear Heap Memory Before Release,
>
> It seems to me that it would be sufficient for the operating
> system to clear the memory before reallocation to a process.
> Why be concerned about the state when no process can access
> it ?
>
Can you, or should you, as the paranoid secure programmer of an
application, trust the OS to do wipe heap memory before it passes the
memory on to another process or even uses it itself?

> Is there a separate item for clearing stack memory ?  That
> would seem vulnerable in the same way

There probably should be one, c.f. GCC Mudflap Pointer Debugging, the
-wipe-stack option at http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

Koo's suggestion makes sense to me (moving 244).

Cheers,
Pascal
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion of Repositioning CWE #244

ljknews
At 8:31 AM -0400 7/7/08, Pascal Meunier wrote:

> ljknews wrote:
>> At 3:08 PM -0400 7/3/08, koo wrote:
>>
>>> We suggest that CWE #244, Failure to Clear Heap Memory Before Release,
>>
>> It seems to me that it would be sufficient for the operating
>> system to clear the memory before reallocation to a process.
>> Why be concerned about the state when no process can access
>> it ?
>>
> Can you, or should you, as the paranoid secure programmer of an
> application, trust the OS to do wipe heap memory before it passes the
> memory on to another process or even uses it itself?

On the operating system I use, absolutely.
--
Larry Kilgallen
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion of Repositioning CWE #244

Robert C. Seacord
In reply to this post by Pascal Meunier-2-3

Pascal & everyone,

Here is the recommendation we wrote for this rule for the C programming language:

MEM03-A. Clear sensitive information stored in reusable resources returned for reuse

Besides the neat use if alliteration, we list the following examples of reusable resources:

  • dynamically allocated memory
  • statically allocated memory
  • automatically allocated (stack) memory
  • memory caches
  • disk
  • disk caches
thanks,
rCs


ljknews wrote:
  
At 3:08 PM -0400 7/3/08, koo wrote:

    
We suggest that CWE #244, Failure to Clear Heap Memory Before Release,
      
It seems to me that it would be sufficient for the operating
system to clear the memory before reallocation to a process.
Why be concerned about the state when no process can access
it ?

    
Can you, or should you, as the paranoid secure programmer of an
application, trust the OS to do wipe heap memory before it passes the
memory on to another process or even uses it itself?

  
Is there a separate item for clearing stack memory ?  That
would seem vulnerable in the same way
    

There probably should be one, c.f. GCC Mudflap Pointer Debugging, the
-wipe-stack option at http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

Koo's suggestion makes sense to me (moving 244).

Cheers,
Pascal
  


-- 
Robert C. Seacord
Senior Vulnerability Analyst
CERT/CC 

Work: 412-268-7608
FAX: 412-268-6989
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion of Repositioning CWE #244

Steven M. Christey-2
In reply to this post by Michael Koo
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
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion of Repositioning CWE #244

Steven M. Christey-2
In reply to this post by ljknews
On Thu, 3 Jul 2008, ljknews wrote:

> At 3:08 PM -0400 7/3/08, koo wrote:
>
> > We suggest that CWE #244, Failure to Clear Heap Memory Before Release,
>
> It seems to me that it would be sufficient for the operating
> system to clear the memory before reallocation to a process.

One thing that I try to do when thinking about classification within CWE
is to separate the solution from the weakness itself.  Most weaknesses
could have multiple solutions.

> Is there a separate item for clearing stack memory ?  That
> would seem vulnerable in the same ways.

We don't have a CWE that's about stack memory.

But, this raises an abstraction question that we've been dealing with, and
which I touched on in the fall of 2007.

The general question is: do we create an individual CWE for stack memory?
How about the other resource types that were mentioned by Robert Seacord?

Both "failure to clear stack memory" and "failure to clear heap memory"
are related to resources.  Their common parent is "memory," which we
currently think of as a fairly basic resource that's reasonable to cover
in CWE.  So maybe there's a conceptual parent, "failure to clear memory."
Then you could go up another level, to the general concept of "resource",
i.e. "failure to clear resource" (which is basically a rephrasing of 404
and/or 459).

This "resource-specific abstraction" happens in other places in CWE, for
example CWE-122 (Heap-based buffer overflow) and CWE-121 (Stack-based
buffer overflow), as well as the various descendants of CWE-552 Files or
Directories Accessible to External Parties; each descendant covers a
different type of file, such as a backup or log file.

The general issue is, how specific must we get in order to create CWEs?
This was discussed in the fall.  A combinatorial explosion could result if
we go too deep; we lose expressiveness if we're not specific enough.
This problem is now less severe since we have abstraction levels (Class,
Base, Variant) - we'll usually label resource-specific abstractions as
variants, so these could be removed from various views that don't want to
go that deep.  It might also be useful to label the "dimension" along
which variants can occur, such as "resource-specific."

If we have this type of data available, then we don't need to reach the
same depth across all of CWE.  We could add new nodes on an "as-needed"
basis if there is sufficient demand for it, and those nodes would exist in
some views, but not others.

In this particular case, the question is - is there a need to create
separate CWE entries for the failure to "clear" different types of memory,
and/or the different types of resources in general?

- Steve