« Return to Thread: Examples of Detailed Changes to Context-Specific CWE Nodes (CONSPEC)
Re: Examples of Detailed Changes to Context-Specific CWE Nodes (CONSPEC)
by Pascal Meunier-3
::
Rate this Message:
Sorry for the delay, but now I've had some time to think about the nodes
you listed.
It seems to me that the following nodes would be adequately grouped
under an abstraction node:
"Suspicious code" or "Code suspected of not matching programmer's
intent" which is really what you mean by "context-specific" in these
cases. "Context-specific" has other meanings in the other CWEs you listed.
CWE-597: Erroneous String Compare
CWE-481: Assigning instead of comparing
CWE-482: Comparing instead of assigning
CWE-570: Expression is Always False
CWE-571: Expression is Always True
CWE-595: Incorrect Object Comparison: Syntactic
CWE-484: Omitted break statement
CWE-128: Wrap-around error
CWE-582: Mobile Code: Unsafe Array Declaration
CWE-583: Mobile Code: Public Finalize Method
These nodes are worth mentioning even if legitimate uses are known or
can be contrived. By grouping them this way (perhaps it could be a
flag?) you also transmit the knowledge that detecting it does not make
the code automatically faulty.
For CWE-588: Attempt to Access Child of a Non-structure Pointer
Isn't this rather the consequence of a prior weakness?
Which would be a "Type mismatch between expected pointer and pointee
types". (I found a use and definition of pointee at
http://cslibrary.stanford.edu/106/) For the sake of completeness, then
you need a node for "Pointer doesn't point to expected object even
though object is of correct type". I suppose one could say even these
were directly caused earlier in the program by another mistake/weakness:
"Pointer assigned to pointee of wrong type"
"Pointer assigned to unintended pointee of correct type"
I suggest going up the chain of "cause" weaknesses when this chain
appears flat and linear (without any branching).
I see a difference between this and the rest of the CWEs you identified:
> CWE-473: PHP External Variable Modification
because the PHP code seems intrinsically correct. That is, you need
outside information (PHP configuration) or consideration (understanding
of how PHP works with Apache) to realize that these are weaknesses. You
can't tell that something is amiss unless you stop looking at your code,
surface, and examine the behaviors of other code and the environment
surrounding it and in which it executes.
I disagree when you say it's context-specific relative to the
programmer's intent. When you say that a variable may not have security
implications, I think that can be very hard to establish, very much like
whether a vulnerability is "exploitable outside of a laboratory". Any
instance of a variable that can be modified externally and does not
undergo input validation before being used is clearly a flaw.
CWE-598: Information Leak Through GET Request
I don't understand what you mean by "some information might be intended
to be captured in a GET request."
If you have this node then you absolutely should have a node for
CWE-598: Information Leak Through POST. Inspecting the source code of
forms, e.g. to find hidden form fields, is trivial.
The "Potential Mitigations" field says "Recommendations include
performing server-side input validation to ensure data received from the
client matches expectations." That's besides the point of the
information leak.
If you want to address the potential manipulation of GET parameters,
that should absolutely be a separate node, right next to manipulation of
POST parameters and under Web Parameter Tampering (472) which should be
a child of input validation (Insufficient Input Validation (20)). This
aspect of the dual-identity of the 598 node is completely inappropriate
under "information leak (200)".
While I'm at it, Modification of Assumed-Immutable Data (MAID) 471
should be under Insufficient Input Validation (20), if you insist on
keeping it. IMO 471 is the ultimate context-dependent node because you
try to divine programmer intent. I think 471 shouldn't be in the CWE.
You could place Insufficient Input Validation (20) under code quality,
the parent of 471, to preserve the chain. This reveals the flaws at the
top level of the CWE. In this case, Data handling (19) (the current
parent of 20) and Code Quality (the parent of 471) overlap (398). It's
a mess.
While talking about ultimate context-dependent nodes, how about
"Intended Information Leak (213)? How can anyone know if it was really
intended, when even the original programmer may forget after sleeping?
Does it matter that it was intended? Probably the info leakage through
a GET or a POST was what I intended to do (perhaps it's even a field in
the visible form!) so these should sometimes be children of 213? Here
we have the statistical quantum CWEs: the position of a node in the
hierarchy can't be determined until the actual flaw is examined, and
programmer intent guessed at. :P
for CWE-568: Erroneous Finalize Method, "Failure to call cleanup method
for parent class" is much clearer. The context is two-fold: did any
parent class define a custom finalize method, and does the language
support the finalize call. It's easy to find that there are many OO
languages that support it (see
http://msdn2.microsoft.com/en-us/library/system.object.finalize.aspx),
Borland Delphi and Ruby. These could be listed in an open-ended
fashion. The other context can be encapsulated in the CWE definition:
"Failure to call parent's finalize method" : "when any object in the
class hierarchy has a custom finalize method, one of the child classes
doesn't call a parent's finalize method." I believe this should always
be true (I can't contrive a case where that wouldn't be the correct
thing to do), and therefore not "context specific" relative to
programmer intent.
CWE-580: Erroneous Clone Method is much more complicated due to nested
objects: this is a "hydra" node :). Sometimes the desired behavior is
for a nested object to be cloned, and sometimes to be created anew.
Sometimes the reference to the nested object should just be copied
("shallow" cloning).
I see that the definition of the CWE is limited to only calling the
super.clone method. In that case the name of the CWE is misleading. It
should be renamed to "Failure to call parent's clone method". The
difference between this and CWE-568 is that I can easily think of cases
where you *don't* want to call the parent's clone method, e.g., when the
desired behavior for nested objects should be different from what the
parent does.
"Erroneous Clone Method" is very vague. What if that means returning an
object of the parent's class instead? that would seem closely related
to "Pointer assigned to pointee of wrong type".
I don't think you can easily escape from that "hydra", and I suggest not
using the same approach as for CWE-568 (Erroneous Finalize Method). I
suppose you could temporarily dodge it by renaming it and delaying
dealing with the other weaknesses that the name suggested.
CWE-581: Object Model Violation: Just One of Equals and Haschode Defined
There's a typo in the name, suggesting illicit substances being used
while coding. Otherwise, I really don't see anything "context-specific"
about it. This could happen in Ruby (I'm sure) and other languages (not
sure which, but most likely) as well so the description should not rule
out other languages when mentioning Java.
Finally, CWE-589: Call to Limited API sounds strange to me. It seems to
have a dual nature and should be split according to the description.
Calling deprecated functions (esp. if deprecated for security reasons)
seems a much different and greater issue than making a call to a limited
API. If part of an API is missing on the platform where it was
deployed, that should simply result in an error, exception or such and
the entire operation stopped. Why is that even a weakness unless we're
talking about firmware in an airplane or life-support equipment, which
in the first place are deployed on well-controlled platforms?
Pascal
Steven M. Christey wrote:
> This is an incomplete list of changes that would be made to CWE nodes
> that are context-specific. Not all affected nodes are listed.
>
> Do these suggested changes make sense? Would they work for your
> purposes? Are we missing anything?
>
> Thanks,
> Steve
>
>
> Introduction
> ------------
>
> Based on MITRE's recommendations as published for context-specific
> nodes, the following changes might take place:
>
> 1) Deprecate an issue if there aren't any reasonable scenarios under
> which the issue would directly impact security of an application.
>
> 2) If a node describes issues that are specific to a particular
> language, framework, or technology, then attempt to generalize the
> node's description and name. Restructure the node so that the
> specific details are treated as "sub-nodes." Note: the mechanisms
> for node restructuring are still being defined; see
> http://cwe.mitre.org/community/research/restructuring.html for a
> more detailed description.
>
>
> === Nodes that might be deprecated ===
>
> These nodes could be deprecated if it cannot be demonstrated that they
> have security relevance.
>
> CWE-575: EJB Bad Practices: Use of AWT Swing
> CWE-576: EJB Bad Practices: Use of JAVA I/O
> CWE-577: EJB Bad Practices: Use of Sockets
>
> === Nodes that might be restructured ===
>
> Note: per the Key Principles for node restructuring, detailed
> information from all deprecated nodes will still be somehow available
> within CWE, although not necessarily within individual nodes.
>
> These nodes might be made more abstract by creating a more general
> node, then either (1) deprecating these specific nodes and merging
> their changes into their parents, or (2) ensuring there is a more
> general node, then making these nodes children of the general node,
> and limiting these children to specific views. More details are
> available in the "Managing Node Restructuring" document.
>
> CWE-580: Erroneous Clone Method
> CWE-568: Erroneous Finalize Method
> CWE-586: Explicit Call to Finalize
> CWE-582: Mobile Code: Unsafe Array Declaration
> CWE-583: Mobile Code: Public Finalize Method
> CWE-574: EJB Bad Practices: Use of Synchronization Primitives
> CWE-575: EJB Bad Practices: Use of AWT Swing
> CWE-576: EJB Bad Practices: Use of JAVA I/O
> CWE-577: EJB Bad Practices: Use of Sockets
> CWE-578: EJB Bad Practices: Use of Class Loader
> CWE-581: Object Model Violation: Just One of Equals and Haschode Defined
> CWE-597: Erroneous String Compare
> CWE-481: Assigning instead of comparing
> CWE-482: Comparing instead of assigning
> CWE-584: Return Inside Finally Block
> CWE-587: Assignment of a Fixed Address to a Pointer
> CWE-588: Attempt to Access Child of a Non-structure Pointer
> CWE-8: J2EE Misconfiguration: Unsafe Bean Declaration
> CWE-9: J2EE Misconfiguration: Weak Access Permissions
>
> === Nodes with Minor changes only ===
>
> CWE-584: Return Inside Finally Block
> CWE-570: Expression is Always False
> CWE-571: Expression is Always True
> CWE-589: Call to Limited API
> CWE-595: Incorrect Object Comparison: Syntactic
> CWE-484: Omitted break statement
> CWE-473: PHP External Variable Modification
> CWE-128: Wrap-around error
> CWE-598: Information Leak Through GET Request
>
>
> ---------------------------------
> Details on Potential Node Changes
> ---------------------------------
>
> CWE-128: Wrap-around error
>
> This is context-specific because wrap-arounds are sometimes
> legitimate functionality, such as when performing mathematical
> calculations.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, relative to CONSPEC,
> although this node has overlap issues with CWE-190 (Integer
> overflow) and other numeric errors (CWE-189)
>
> CWE-580: Erroneous Clone Method
>
> This probably is not a context-specific issue. It seems unlikely
> that the developer would intend to cause the wrong type of object to
> be returned.
>
> POSSIBLE CHANGES:
>
> 1) This is very similar to CWE-568 (Erroneous Finalize Method), so
> the same kinds of changes could be made.
>
> CWE-568: Erroneous Finalize Method
>
> This is context-specific because there might be some cases in which
> it is intentional, correct behavior NOT to call a finalize method.
> It seems reasonable that this issue would sometimes have security
> relevance, e.g. by causing an inconsistent state that could be
> leveraged by an attacker, so the essential nature of the node should
> remain in CWE.
>
> POSSIBLE CHANGES:
>
> 1) If there are other OO languages that have equivalent notions of
> calling a super's method before, then generalize this node's
> description to handle those OO languages. For example, this node
> could be renamed to "Failure to call cleanup method for parent
> class"
>
> 2) No new language-specific nodes would be created.
>
> 3) The Applicable Platforms attribute would be updated to handle
> other relevant languages besides Java.
>
> CWE-586: Explicit Call to Finalize
>
> This is context-specific because there might be some some cases in
> which it is intentional, correct behavior to call finalize() from
> outside the finalizer.
>
> POSSIBLE CHANGES:
>
> 1) This node could be abstracted to "Call to method/function outside
> of its intended scope". This would also cover other similar
> errors that are not specific to Java.
>
> 2) At least, the name needs to be changed, since the current
> implication is that any use of finalize() could be a weakness.
>
> CWE-583: Mobile Code: Public Finalize Method
>
> It is not clear whether this is context-specific; are there any
> cases in which a finalize() method should be over-ridable?
>
> POSSIBLE CHANGES:
>
> 1) The description and name could be generalized to make it less
> Java-specific.
>
> 2) There are other CWE nodes related to "access to protected stuff"
> (such as CWE-582), as well as other nodes related to "finalize"
> (such as CWE-568). This suggests that there is likely a more
> general node that could be created, and this specific node might
> need to support multiple views.
>
> CWE-582: Mobile Code: Unsafe Array Declaration
>
> This is context-specific because there might be some cases in which
> it is intentional, correct behavior to make an array public, final
> and static.
>
> POSSIBLE CHANGES:
>
> 1) This node could be made more abstract, such as "Failure to
> protect internal data structures," and the Java-specific variant
> for arrays could be a sub-node.
>
> CWE-574: EJB Bad Practices: Use of Synchronization Primitives
>
> This is context-specific because there might be some limited cases
> in which synchronization primitives are intentional, correct
> behavior. It seems reasonable that this issue would sometimes have
> security relevance, e.g. by causing an inconsistent state that could
> be leveraged by an attacker, so the essential nature of the node
> should remain in CWE.
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. This node's name and description could be
> rephrased to become independent of the specific framework, such
> as "Use of primitives in violation of specification." If it's decided
> that "sub-nodes" are full-fledged nodes within CWE, then this
> could remain specific to EJB, restricted to certain views, and a
> new node would need to be created for the more general issue.
>
> However, this would make it very similar to the general node that
> might arise from restructuring for CWE-575; this might argue that
> a general node could be created that is the parent for both
> CWE-574 and CWE-575.
>
> 2) This node is already a child of CWE-573 (Failure to Follow
> Specification), but CWE-573 seems to be too high-level for most
> use-cases, so this node should not be merged into CWE-573.
>
> CWE-575: EJB Bad Practices: Use of AWT Swing
>
> This is context-specific because there might be some limited cases
> in which an application needs to interact directly with the keyboard
> or display.
>
> POSSIBLE CHANGES:
>
> 1) Perhaps this node should be deprecated from CWE, unless it can be
> demonstrated that keyboard/display interactions have a direct
> role in other issues. If so, then this should be documented
> closely, since public sources do not adequately explain why this
> issue is security-relevant.
>
> 2) RESTRUCTURING. This node's name and description could be
> rephrased to become independent of the specific framework and
> package being used, such as "Use of low-level packages in
> violation of specification."
>
> However, this would make it very similar to the general node that
> might arise from restructuring for CWE-574; this might argue that
> a general node could be created that is the parent for both
> CWE-574 and CWE-575.
>
> 3) This node is already a child of CWE-573 (Failure to Follow
> Specification), but CWE-573 seems to be too high-level for most
> use-cases, so this node should not be merged into CWE-573.
>
>
> CWE-576: EJB Bad Practices: Use of JAVA I/O
>
> This is context-specific because there might be some limited cases
> in which an application has a legitimate requirement for the java.io
> package package.
>
> POSSIBLE CHANGES:
>
> 1) DEPRECATION. Perhaps this node should be deprecated from CWE,
> unless it can be demonstrated how low-level I/O has a
> security-relevant role. If there is such a role, then this
> should be documented closely, since public sources do not
> adequately explain why this issue is security-relevant.
>
> 2) RESTRUCTURING. This seems to be very similar to CWE-575; the
> main difference is in what package/code repository is being used.
> Consequently, this could be restructured so that there's a
> generalized node that subsumes both CWE-575 and CWE-576.
>
> CWE-577: EJB Bad Practices: Use of Sockets
>
> This is context-specific because there might be some limited cases
> in which an application has a legitimate requirement for directly
> using sockets.
>
> POSSIBLE CHANGES:
>
> 1) DEPRECATION. Perhaps this node should be deprecated from CWE,
> unless it can be demonstrated how the use of sockets poses a
> security-relevant role. If there is such a role, then this
> should be documented closely, since public sources do not
> adequately explain why this issue is security-relevant.
>
> 2) RESTRUCTURING. This node is not much different than CWE-574,
> CWE-575, and CWE-576, so the same restructuring might apply.
>
> CWE-578: EJB Bad Practices: Use of Class Loader
>
> This is context-specific because there might be some limited cases
> in which an application has a legitimate requirement for using the
> class loader. Current sources do not explicitly state the security
> implications of this choice, although the EJB specification does
> state that this "could compromise security".
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. This node is not much different than CWE-574,
> CWE-575, CWE-576, and CWE-577, so the same restructuring might
> apply.
>
> CWE-581: Object Model Violation: Just One of Equals and Haschode Defined
>
> It is not clear whether this is context-specific; are there any
> cases in which only one of Equals/Hashcode would need to be defined?
> The security implications are fairly clear, since this affects
> notions of "equality" and "equivalence," and many attacks involve
> using equivalence manipulations to bypass protection mechanisms.
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. A more abstract node could be created, perhaps
> "Failure to implement proper object equivalence," and this would
> be a language-specific sub-node.
>
> CWE-595: Incorrect Object Comparison: Syntactic
>
> This is context-specific because there might be some limited cases
> in which the programmer intends to compare references (or specific
> objects) instead of their implicit values.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, although the description
> should be extended to make it clear what is meant by "syntactic",
> and the security-relevant areas in which this weakness might
> appear, such as security-critical decisions in which multiple
> objects might be equivalent. Also, its existing parents (569
> Expression Issues, 398 Code Quality) are more like grouping nodes
> than weakness-focused parents.
>
> CWE-597: Erroneous String Compare
>
> This is context-specific because there might be some extremely
> limited circumstances in which the programmer might intend to
> compare strings using "==". (While this might be bad practice, the
> security relevance of such a decision would still be
> context-specific.)
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. Since this node is the only child of CWE-595
> (Incorrect Object Comparison: Syntactic), some restructuring
> might be necessary, such as creating additional children for
> CWE-595, or other restructuring.
>
> CWE-481: Assigning instead of comparing
>
> This is context-specific since a common programming idiom is to
> perform an assignment within a conditional, and this action is often
> intentional and legitimate. (While this might be bad practice, the
> security relevance of such a decision would still be
> context-specific.)
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, although this node could
> use a weakness-focused parent; its existing parent (569
> Expression Issues) is more of a grouping node than a "real"
> parent. CWE-480 (Using the wrong operator) seems appropriate.
>
> 2) RESTRUCTURING. CWE-481 (Assigning instead of comparing) and its
> sibling CWE-482 (Comparing instead of assigning) might be too
> low-level for some use-cases, although this is probably an
> important distinction with Assessment Vendors and Assessment
> Customers. At least, there is a close relationship with CWE-480.
>
> CWE-482: Comparing instead of assigning
>
> The same changes would apply as for CWE-481.
>
> CWE-584: Return Inside Finally Block
>
> This is context-specific because there might be some cases in which
> it is intentional, correct behavior to discard any possible
> exception that might occur. The security relevance is clear, since
> this weakness could leave the software in an unexpected state that
> was not properly detected.
>
> POSSIBLE CHANGES:
>
> 1) The node could be left largely unchanged. Perhaps the
> description and name could be generalized, but it's already
> fairly general. One option might be to generalize the node to
> "return without catching all relevant exceptions."
>
> CWE-484: Omitted break statement
>
> This is context-specific because the omission of a break might still
> produce correct behavior.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, although this node could
> use a weakness-focused parent; its existing parent (398 Code
> Quality) is more of a grouping node than a "real" parent. It's
> not clear what a good parent might be.
>
> CWE-587: Assignment of a Fixed Address to a Pointer
>
> It's not clear whether this is really a context-specific issue; are
> there cases in which it is reasonable to assign a pointer to a
> specific address? Possibly for backwards compatibility,
> implementing function hooks, inline patching, or optimization. The
> security implications are obvious, however, when considering the
> possible use of this idiom in the context of Trojan horses.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary. However, this is only
> listed as a child of 465 (Pointer Issues), which is effectively a
> grouping node instead of a "real" parent weakness. A more
> abstract node could be created to handle the "real" parent
> weakness, but it's not clear what that node might be.
>
>
>
> It's not clear whether this is realy a context-specific issue; are
> there cases in which it's appropriate to cast a non-structure to a
> structure? This might be common in parsers for complex data
> representations with many types, such as document or image
> processors.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary. However, this is only
> listed as a child of 465 (Pointer Issues), which is effectively a
> grouping node instead of a "real" parent weakness. A more
> abstract node could be created to handle the "real" parent
> weakness, but what would such a node look like?
>
you listed.
It seems to me that the following nodes would be adequately grouped
under an abstraction node:
"Suspicious code" or "Code suspected of not matching programmer's
intent" which is really what you mean by "context-specific" in these
cases. "Context-specific" has other meanings in the other CWEs you listed.
CWE-597: Erroneous String Compare
CWE-481: Assigning instead of comparing
CWE-482: Comparing instead of assigning
CWE-570: Expression is Always False
CWE-571: Expression is Always True
CWE-595: Incorrect Object Comparison: Syntactic
CWE-484: Omitted break statement
CWE-128: Wrap-around error
CWE-582: Mobile Code: Unsafe Array Declaration
CWE-583: Mobile Code: Public Finalize Method
These nodes are worth mentioning even if legitimate uses are known or
can be contrived. By grouping them this way (perhaps it could be a
flag?) you also transmit the knowledge that detecting it does not make
the code automatically faulty.
For CWE-588: Attempt to Access Child of a Non-structure Pointer
Isn't this rather the consequence of a prior weakness?
Which would be a "Type mismatch between expected pointer and pointee
types". (I found a use and definition of pointee at
http://cslibrary.stanford.edu/106/) For the sake of completeness, then
you need a node for "Pointer doesn't point to expected object even
though object is of correct type". I suppose one could say even these
were directly caused earlier in the program by another mistake/weakness:
"Pointer assigned to pointee of wrong type"
"Pointer assigned to unintended pointee of correct type"
I suggest going up the chain of "cause" weaknesses when this chain
appears flat and linear (without any branching).
I see a difference between this and the rest of the CWEs you identified:
> CWE-473: PHP External Variable Modification
because the PHP code seems intrinsically correct. That is, you need
outside information (PHP configuration) or consideration (understanding
of how PHP works with Apache) to realize that these are weaknesses. You
can't tell that something is amiss unless you stop looking at your code,
surface, and examine the behaviors of other code and the environment
surrounding it and in which it executes.
I disagree when you say it's context-specific relative to the
programmer's intent. When you say that a variable may not have security
implications, I think that can be very hard to establish, very much like
whether a vulnerability is "exploitable outside of a laboratory". Any
instance of a variable that can be modified externally and does not
undergo input validation before being used is clearly a flaw.
CWE-598: Information Leak Through GET Request
I don't understand what you mean by "some information might be intended
to be captured in a GET request."
If you have this node then you absolutely should have a node for
CWE-598: Information Leak Through POST. Inspecting the source code of
forms, e.g. to find hidden form fields, is trivial.
The "Potential Mitigations" field says "Recommendations include
performing server-side input validation to ensure data received from the
client matches expectations." That's besides the point of the
information leak.
If you want to address the potential manipulation of GET parameters,
that should absolutely be a separate node, right next to manipulation of
POST parameters and under Web Parameter Tampering (472) which should be
a child of input validation (Insufficient Input Validation (20)). This
aspect of the dual-identity of the 598 node is completely inappropriate
under "information leak (200)".
While I'm at it, Modification of Assumed-Immutable Data (MAID) 471
should be under Insufficient Input Validation (20), if you insist on
keeping it. IMO 471 is the ultimate context-dependent node because you
try to divine programmer intent. I think 471 shouldn't be in the CWE.
You could place Insufficient Input Validation (20) under code quality,
the parent of 471, to preserve the chain. This reveals the flaws at the
top level of the CWE. In this case, Data handling (19) (the current
parent of 20) and Code Quality (the parent of 471) overlap (398). It's
a mess.
While talking about ultimate context-dependent nodes, how about
"Intended Information Leak (213)? How can anyone know if it was really
intended, when even the original programmer may forget after sleeping?
Does it matter that it was intended? Probably the info leakage through
a GET or a POST was what I intended to do (perhaps it's even a field in
the visible form!) so these should sometimes be children of 213? Here
we have the statistical quantum CWEs: the position of a node in the
hierarchy can't be determined until the actual flaw is examined, and
programmer intent guessed at. :P
for CWE-568: Erroneous Finalize Method, "Failure to call cleanup method
for parent class" is much clearer. The context is two-fold: did any
parent class define a custom finalize method, and does the language
support the finalize call. It's easy to find that there are many OO
languages that support it (see
http://msdn2.microsoft.com/en-us/library/system.object.finalize.aspx),
Borland Delphi and Ruby. These could be listed in an open-ended
fashion. The other context can be encapsulated in the CWE definition:
"Failure to call parent's finalize method" : "when any object in the
class hierarchy has a custom finalize method, one of the child classes
doesn't call a parent's finalize method." I believe this should always
be true (I can't contrive a case where that wouldn't be the correct
thing to do), and therefore not "context specific" relative to
programmer intent.
CWE-580: Erroneous Clone Method is much more complicated due to nested
objects: this is a "hydra" node :). Sometimes the desired behavior is
for a nested object to be cloned, and sometimes to be created anew.
Sometimes the reference to the nested object should just be copied
("shallow" cloning).
I see that the definition of the CWE is limited to only calling the
super.clone method. In that case the name of the CWE is misleading. It
should be renamed to "Failure to call parent's clone method". The
difference between this and CWE-568 is that I can easily think of cases
where you *don't* want to call the parent's clone method, e.g., when the
desired behavior for nested objects should be different from what the
parent does.
"Erroneous Clone Method" is very vague. What if that means returning an
object of the parent's class instead? that would seem closely related
to "Pointer assigned to pointee of wrong type".
I don't think you can easily escape from that "hydra", and I suggest not
using the same approach as for CWE-568 (Erroneous Finalize Method). I
suppose you could temporarily dodge it by renaming it and delaying
dealing with the other weaknesses that the name suggested.
CWE-581: Object Model Violation: Just One of Equals and Haschode Defined
There's a typo in the name, suggesting illicit substances being used
while coding. Otherwise, I really don't see anything "context-specific"
about it. This could happen in Ruby (I'm sure) and other languages (not
sure which, but most likely) as well so the description should not rule
out other languages when mentioning Java.
Finally, CWE-589: Call to Limited API sounds strange to me. It seems to
have a dual nature and should be split according to the description.
Calling deprecated functions (esp. if deprecated for security reasons)
seems a much different and greater issue than making a call to a limited
API. If part of an API is missing on the platform where it was
deployed, that should simply result in an error, exception or such and
the entire operation stopped. Why is that even a weakness unless we're
talking about firmware in an airplane or life-support equipment, which
in the first place are deployed on well-controlled platforms?
Pascal
Steven M. Christey wrote:
> This is an incomplete list of changes that would be made to CWE nodes
> that are context-specific. Not all affected nodes are listed.
>
> Do these suggested changes make sense? Would they work for your
> purposes? Are we missing anything?
>
> Thanks,
> Steve
>
>
> Introduction
> ------------
>
> Based on MITRE's recommendations as published for context-specific
> nodes, the following changes might take place:
>
> 1) Deprecate an issue if there aren't any reasonable scenarios under
> which the issue would directly impact security of an application.
>
> 2) If a node describes issues that are specific to a particular
> language, framework, or technology, then attempt to generalize the
> node's description and name. Restructure the node so that the
> specific details are treated as "sub-nodes." Note: the mechanisms
> for node restructuring are still being defined; see
> http://cwe.mitre.org/community/research/restructuring.html for a
> more detailed description.
>
>
> === Nodes that might be deprecated ===
>
> These nodes could be deprecated if it cannot be demonstrated that they
> have security relevance.
>
> CWE-575: EJB Bad Practices: Use of AWT Swing
> CWE-576: EJB Bad Practices: Use of JAVA I/O
> CWE-577: EJB Bad Practices: Use of Sockets
>
> === Nodes that might be restructured ===
>
> Note: per the Key Principles for node restructuring, detailed
> information from all deprecated nodes will still be somehow available
> within CWE, although not necessarily within individual nodes.
>
> These nodes might be made more abstract by creating a more general
> node, then either (1) deprecating these specific nodes and merging
> their changes into their parents, or (2) ensuring there is a more
> general node, then making these nodes children of the general node,
> and limiting these children to specific views. More details are
> available in the "Managing Node Restructuring" document.
>
> CWE-580: Erroneous Clone Method
> CWE-568: Erroneous Finalize Method
> CWE-586: Explicit Call to Finalize
> CWE-582: Mobile Code: Unsafe Array Declaration
> CWE-583: Mobile Code: Public Finalize Method
> CWE-574: EJB Bad Practices: Use of Synchronization Primitives
> CWE-575: EJB Bad Practices: Use of AWT Swing
> CWE-576: EJB Bad Practices: Use of JAVA I/O
> CWE-577: EJB Bad Practices: Use of Sockets
> CWE-578: EJB Bad Practices: Use of Class Loader
> CWE-581: Object Model Violation: Just One of Equals and Haschode Defined
> CWE-597: Erroneous String Compare
> CWE-481: Assigning instead of comparing
> CWE-482: Comparing instead of assigning
> CWE-584: Return Inside Finally Block
> CWE-587: Assignment of a Fixed Address to a Pointer
> CWE-588: Attempt to Access Child of a Non-structure Pointer
> CWE-8: J2EE Misconfiguration: Unsafe Bean Declaration
> CWE-9: J2EE Misconfiguration: Weak Access Permissions
>
> === Nodes with Minor changes only ===
>
> CWE-584: Return Inside Finally Block
> CWE-570: Expression is Always False
> CWE-571: Expression is Always True
> CWE-589: Call to Limited API
> CWE-595: Incorrect Object Comparison: Syntactic
> CWE-484: Omitted break statement
> CWE-473: PHP External Variable Modification
> CWE-128: Wrap-around error
> CWE-598: Information Leak Through GET Request
>
>
> ---------------------------------
> Details on Potential Node Changes
> ---------------------------------
>
> CWE-128: Wrap-around error
>
> This is context-specific because wrap-arounds are sometimes
> legitimate functionality, such as when performing mathematical
> calculations.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, relative to CONSPEC,
> although this node has overlap issues with CWE-190 (Integer
> overflow) and other numeric errors (CWE-189)
>
> CWE-580: Erroneous Clone Method
>
> This probably is not a context-specific issue. It seems unlikely
> that the developer would intend to cause the wrong type of object to
> be returned.
>
> POSSIBLE CHANGES:
>
> 1) This is very similar to CWE-568 (Erroneous Finalize Method), so
> the same kinds of changes could be made.
>
> CWE-568: Erroneous Finalize Method
>
> This is context-specific because there might be some cases in which
> it is intentional, correct behavior NOT to call a finalize method.
> It seems reasonable that this issue would sometimes have security
> relevance, e.g. by causing an inconsistent state that could be
> leveraged by an attacker, so the essential nature of the node should
> remain in CWE.
>
> POSSIBLE CHANGES:
>
> 1) If there are other OO languages that have equivalent notions of
> calling a super's method before, then generalize this node's
> description to handle those OO languages. For example, this node
> could be renamed to "Failure to call cleanup method for parent
> class"
>
> 2) No new language-specific nodes would be created.
>
> 3) The Applicable Platforms attribute would be updated to handle
> other relevant languages besides Java.
>
> CWE-586: Explicit Call to Finalize
>
> This is context-specific because there might be some some cases in
> which it is intentional, correct behavior to call finalize() from
> outside the finalizer.
>
> POSSIBLE CHANGES:
>
> 1) This node could be abstracted to "Call to method/function outside
> of its intended scope". This would also cover other similar
> errors that are not specific to Java.
>
> 2) At least, the name needs to be changed, since the current
> implication is that any use of finalize() could be a weakness.
>
> CWE-583: Mobile Code: Public Finalize Method
>
> It is not clear whether this is context-specific; are there any
> cases in which a finalize() method should be over-ridable?
>
> POSSIBLE CHANGES:
>
> 1) The description and name could be generalized to make it less
> Java-specific.
>
> 2) There are other CWE nodes related to "access to protected stuff"
> (such as CWE-582), as well as other nodes related to "finalize"
> (such as CWE-568). This suggests that there is likely a more
> general node that could be created, and this specific node might
> need to support multiple views.
>
> CWE-582: Mobile Code: Unsafe Array Declaration
>
> This is context-specific because there might be some cases in which
> it is intentional, correct behavior to make an array public, final
> and static.
>
> POSSIBLE CHANGES:
>
> 1) This node could be made more abstract, such as "Failure to
> protect internal data structures," and the Java-specific variant
> for arrays could be a sub-node.
>
> CWE-574: EJB Bad Practices: Use of Synchronization Primitives
>
> This is context-specific because there might be some limited cases
> in which synchronization primitives are intentional, correct
> behavior. It seems reasonable that this issue would sometimes have
> security relevance, e.g. by causing an inconsistent state that could
> be leveraged by an attacker, so the essential nature of the node
> should remain in CWE.
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. This node's name and description could be
> rephrased to become independent of the specific framework, such
> as "Use of primitives in violation of specification." If it's decided
> that "sub-nodes" are full-fledged nodes within CWE, then this
> could remain specific to EJB, restricted to certain views, and a
> new node would need to be created for the more general issue.
>
> However, this would make it very similar to the general node that
> might arise from restructuring for CWE-575; this might argue that
> a general node could be created that is the parent for both
> CWE-574 and CWE-575.
>
> 2) This node is already a child of CWE-573 (Failure to Follow
> Specification), but CWE-573 seems to be too high-level for most
> use-cases, so this node should not be merged into CWE-573.
>
> CWE-575: EJB Bad Practices: Use of AWT Swing
>
> This is context-specific because there might be some limited cases
> in which an application needs to interact directly with the keyboard
> or display.
>
> POSSIBLE CHANGES:
>
> 1) Perhaps this node should be deprecated from CWE, unless it can be
> demonstrated that keyboard/display interactions have a direct
> role in other issues. If so, then this should be documented
> closely, since public sources do not adequately explain why this
> issue is security-relevant.
>
> 2) RESTRUCTURING. This node's name and description could be
> rephrased to become independent of the specific framework and
> package being used, such as "Use of low-level packages in
> violation of specification."
>
> However, this would make it very similar to the general node that
> might arise from restructuring for CWE-574; this might argue that
> a general node could be created that is the parent for both
> CWE-574 and CWE-575.
>
> 3) This node is already a child of CWE-573 (Failure to Follow
> Specification), but CWE-573 seems to be too high-level for most
> use-cases, so this node should not be merged into CWE-573.
>
>
> CWE-576: EJB Bad Practices: Use of JAVA I/O
>
> This is context-specific because there might be some limited cases
> in which an application has a legitimate requirement for the java.io
> package package.
>
> POSSIBLE CHANGES:
>
> 1) DEPRECATION. Perhaps this node should be deprecated from CWE,
> unless it can be demonstrated how low-level I/O has a
> security-relevant role. If there is such a role, then this
> should be documented closely, since public sources do not
> adequately explain why this issue is security-relevant.
>
> 2) RESTRUCTURING. This seems to be very similar to CWE-575; the
> main difference is in what package/code repository is being used.
> Consequently, this could be restructured so that there's a
> generalized node that subsumes both CWE-575 and CWE-576.
>
> CWE-577: EJB Bad Practices: Use of Sockets
>
> This is context-specific because there might be some limited cases
> in which an application has a legitimate requirement for directly
> using sockets.
>
> POSSIBLE CHANGES:
>
> 1) DEPRECATION. Perhaps this node should be deprecated from CWE,
> unless it can be demonstrated how the use of sockets poses a
> security-relevant role. If there is such a role, then this
> should be documented closely, since public sources do not
> adequately explain why this issue is security-relevant.
>
> 2) RESTRUCTURING. This node is not much different than CWE-574,
> CWE-575, and CWE-576, so the same restructuring might apply.
>
> CWE-578: EJB Bad Practices: Use of Class Loader
>
> This is context-specific because there might be some limited cases
> in which an application has a legitimate requirement for using the
> class loader. Current sources do not explicitly state the security
> implications of this choice, although the EJB specification does
> state that this "could compromise security".
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. This node is not much different than CWE-574,
> CWE-575, CWE-576, and CWE-577, so the same restructuring might
> apply.
>
> CWE-581: Object Model Violation: Just One of Equals and Haschode Defined
>
> It is not clear whether this is context-specific; are there any
> cases in which only one of Equals/Hashcode would need to be defined?
> The security implications are fairly clear, since this affects
> notions of "equality" and "equivalence," and many attacks involve
> using equivalence manipulations to bypass protection mechanisms.
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. A more abstract node could be created, perhaps
> "Failure to implement proper object equivalence," and this would
> be a language-specific sub-node.
>
> CWE-595: Incorrect Object Comparison: Syntactic
>
> This is context-specific because there might be some limited cases
> in which the programmer intends to compare references (or specific
> objects) instead of their implicit values.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, although the description
> should be extended to make it clear what is meant by "syntactic",
> and the security-relevant areas in which this weakness might
> appear, such as security-critical decisions in which multiple
> objects might be equivalent. Also, its existing parents (569
> Expression Issues, 398 Code Quality) are more like grouping nodes
> than weakness-focused parents.
>
> CWE-597: Erroneous String Compare
>
> This is context-specific because there might be some extremely
> limited circumstances in which the programmer might intend to
> compare strings using "==". (While this might be bad practice, the
> security relevance of such a decision would still be
> context-specific.)
>
> POSSIBLE CHANGES:
>
> 1) RESTRUCTURING. Since this node is the only child of CWE-595
> (Incorrect Object Comparison: Syntactic), some restructuring
> might be necessary, such as creating additional children for
> CWE-595, or other restructuring.
>
> CWE-481: Assigning instead of comparing
>
> This is context-specific since a common programming idiom is to
> perform an assignment within a conditional, and this action is often
> intentional and legitimate. (While this might be bad practice, the
> security relevance of such a decision would still be
> context-specific.)
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, although this node could
> use a weakness-focused parent; its existing parent (569
> Expression Issues) is more of a grouping node than a "real"
> parent. CWE-480 (Using the wrong operator) seems appropriate.
>
> 2) RESTRUCTURING. CWE-481 (Assigning instead of comparing) and its
> sibling CWE-482 (Comparing instead of assigning) might be too
> low-level for some use-cases, although this is probably an
> important distinction with Assessment Vendors and Assessment
> Customers. At least, there is a close relationship with CWE-480.
>
> CWE-482: Comparing instead of assigning
>
> The same changes would apply as for CWE-481.
>
> CWE-584: Return Inside Finally Block
>
> This is context-specific because there might be some cases in which
> it is intentional, correct behavior to discard any possible
> exception that might occur. The security relevance is clear, since
> this weakness could leave the software in an unexpected state that
> was not properly detected.
>
> POSSIBLE CHANGES:
>
> 1) The node could be left largely unchanged. Perhaps the
> description and name could be generalized, but it's already
> fairly general. One option might be to generalize the node to
> "return without catching all relevant exceptions."
>
> CWE-484: Omitted break statement
>
> This is context-specific because the omission of a break might still
> produce correct behavior.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary, although this node could
> use a weakness-focused parent; its existing parent (398 Code
> Quality) is more of a grouping node than a "real" parent. It's
> not clear what a good parent might be.
>
> CWE-587: Assignment of a Fixed Address to a Pointer
>
> It's not clear whether this is really a context-specific issue; are
> there cases in which it is reasonable to assign a pointer to a
> specific address? Possibly for backwards compatibility,
> implementing function hooks, inline patching, or optimization. The
> security implications are obvious, however, when considering the
> possible use of this idiom in the context of Trojan horses.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary. However, this is only
> listed as a child of 465 (Pointer Issues), which is effectively a
> grouping node instead of a "real" parent weakness. A more
> abstract node could be created to handle the "real" parent
> weakness, but it's not clear what that node might be.
>
>
>
> It's not clear whether this is realy a context-specific issue; are
> there cases in which it's appropriate to cast a non-structure to a
> structure? This might be common in parsers for complex data
> representations with many types, such as document or image
> processors.
>
> POSSIBLE CHANGES:
>
> 1) No significant changes seem necessary. However, this is only
> listed as a child of 465 (Pointer Issues), which is effectively a
> grouping node instead of a "real" parent weakness. A more
> abstract node could be created to handle the "real" parent
> weakness, but what would such a node look like?
>
« Return to Thread: Examples of Detailed Changes to Context-Specific CWE Nodes (CONSPEC)
| Free embeddable forum powered by Nabble | Forum Help |
