« Return to Thread: Suggestion of Repositioning CWE #244
Re: Suggestion of Repositioning CWE #244
by Steven M. Christey-2
::
Rate this Message:
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
> 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
« Return to Thread: Suggestion of Repositioning CWE #244
| Free embeddable forum powered by Nabble | Forum Help |
