Examples of Detailed Changes to Context-Specific CWE Nodes (CONSPEC)

[Steven M. Christey-2]

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.

CWE-588: Attempt to Access Child of a Non-structure Pointer

  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?

CWE-570: Expression is Always False

  This is context-specific because the programmer might intentionally
  use an expression that is always false, such as when using a block
  of debugging code that could be enabled easily if necessary.  (While
  this might be bad practice, the security relevance of such a
  decision would still be context-specific, especially when using
  tools that cannot model the programmer's intentions).

  POSSIBLE CHANGES:

  1) No significant changes seem necessary, although this node might
     need a weakness-focused parent; its existing parents (569
     Expression Issues, 561 Dead Code) are more like grouping nodes
     than "real" parents.

CWE-571: Expression is Always True

  This is context-specific because the programmer might intentionally
  use an expression that is always true, such as using the code as a
  placeholder for future enhancements.  (While this might be bad
  practice, the security relevance of such a decision would still be
  context-specific, especially when using tools that cannot model the
  programmer's intentions).

  POSSIBLE CHANGES:

  1) No significant changes seem necessary, although this node might
     need a weakness-focused parent; its existing parents (569
     Expression Issues, 561 Dead Code) are more like grouping nodes
     than "real" parents.

  2) CWE-561 (Dead Code) is not an appropriate parent, because if an
     expression is always true, then if it's reachable, the relevant
     block will always be executed (although it could be argued that
     the "else" portion of the block, if it exists, is dead code).
     This subtlety is important to consider when extending views and
     relationships.

CWE-8: J2EE Misconfiguration: Unsafe Bean Declaration

  This is context-specific since there might be some legitimate
  reasons for exposing a remote interface for an entity bean.

  POSSIBLE CHANGES:

  1) RESTRUCTURING.  CWE-8's parent, "J2EE Environment Issues," is not
     weakness-focused.  So, a more general weakness-focused node could
     be added as a parent.  There are other CWE nodes related to
     "access to protected stuff" (such as CWE-582 and CWE-583, listed
     elsewhere in this document).

  2) The description and name should be changed to better identify the
     weakness.

  3) Since CWE-9 is a technology-specific variant of a more general
     problem, it could be affected by the TECHSPEC discussion point.

CWE-9: J2EE Misconfiguration: Weak Access Permissions

  This is context-specific since the correct permissions/privileges
  can only be defined in terms of the application's own intended
  security policy.

  POSSIBLE CHANGES:

  1) RESTRUCTURING.  CWE-9's parent, "J2EE Environment Issues," is a
     technology-specific grouping node - it's not weakness-focused.  A
     separate parent should be added that is weakness-focused,
     possibly CWE-275 (Permission Issues), although this isn't
     weakness-focused either.  As CWE-9 is currently described, a
     better weakness-focused parent is probably CWE-266 (Incorrect
     Privilege Assignment).

  2) Since CWE-9 is a technology-specific variant of a more general
     problem, it could be affected by the TECHSPEC discussion point.

CWE-589: Call to Limited API

  This is context-specific in that the software might only be intended
  to run on platforms that support the limited API.

  POSSIBLE CHANGES:

  1) No significant changes seem necessary.


CWE-598: Information Leak Through GET Request

  This is context-specific because the notion of "sensitive
  information" can be dependent on the application's own intended
  security policy; some information might be intended to be captured
  in a GET request.

  POSSIBLE CHANGES:

  1) With respect to CONSPEC, no significant changes seem necessary,
     although the description should be clarified.  However, this node
     is a resource-specific variant with many low-level siblings, and
     thus is covered by the RESSPEC discussion point, which might lead
     to significant modifications once RESSPEC has been sufficiently
     evaluated by the researcher community.

CWE-473: PHP External Variable Modification

  This is context-specific because many variables that can be
  modified, are either intended to be modified by the user, or do not
  have security implications.

  POSSIBLE CHANGES:

  1) With respect to CONSPEC, no significant changes seem necessary,
     although minor modifications to the name and description might be
     in order.

[Sean Barnum]

On the list of nodes to potentially deprecate, I suggest we go to the source of these nodes and ask them to explain their thoughts on the security implications of each. Why did they include them?

On the topic of potential node restructuring, I know that methods have not been settled but I would strongly suggest that we use the "(1) deprecating these specific nodes and merging their changes into their parents" choice very, very, very sparingly. It is much preferable to utilize the view-centric "2) ensuring there is a more general node, then making these nodes children of the general node, and limiting these children to specific views" choice.

As far as proposed detailed changes, this email has a bit too much content to cover and comment on quickly. I will try to give feedback on individual items soon.

Sean Barnum

-----Original Message-----
From: owner-cwe-research-list@... [mailto:owner-cwe-research-list@...] On Behalf Of Steven M. Christey
Sent: Monday, September 17, 2007 8:09 PM
To: CWE-RESEARCH-LIST@...
Subject: Examples of Detailed Changes to Context-Specific CWE Nodes (CONSPEC)

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.

CWE-588: Attempt to Access Child of a Non-structure Pointer

  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?

CWE-570: Expression is Always False

  This is context-specific because the programmer might intentionally
  use an expression that is always false, such as when using a block
  of debugging code that could be enabled easily if necessary.  (While
  this might be bad practice, the security relevance of such a
  decision would still be context-specific, especially when using
  tools that cannot model the programmer's intentions).

  POSSIBLE CHANGES:

  1) No significant changes seem necessary, although this node might
     need a weakness-focused parent; its existing parents (569
     Expression Issues, 561 Dead Code) are more like grouping nodes
     than "real" parents.

CWE-571: Expression is Always True

  This is context-specific because the programmer might intentionally
  use an expression that is always true, such as using the code as a
  placeholder for future enhancements.  (While this might be bad
  practice, the security relevance of such a decision would still be
  context-specific, especially when using tools that cannot model the
  programmer's intentions).

  POSSIBLE CHANGES:

  1) No significant changes seem necessary, although this node might
     need a weakness-focused parent; its existing parents (569
     Expression Issues, 561 Dead Code) are more like grouping nodes
     than "real" parents.

  2) CWE-561 (Dead Code) is not an appropriate parent, because if an
     expression is always true, then if it's reachable, the relevant
     block will always be executed (although it could be argued that
     the "else" portion of the block, if it exists, is dead code).
     This subtlety is important to consider when extending views and
     relationships.

CWE-8: J2EE Misconfiguration: Unsafe Bean Declaration

  This is context-specific since there might be some legitimate
  reasons for exposing a remote interface for an entity bean.

  POSSIBLE CHANGES:

  1) RESTRUCTURING.  CWE-8's parent, "J2EE Environment Issues," is not
     weakness-focused.  So, a more general weakness-focused node could
     be added as a parent.  There are other CWE nodes related to
     "access to protected stuff" (such as CWE-582 and CWE-583, listed
     elsewhere in this document).

  2) The description and name should be changed to better identify the
     weakness.

  3) Since CWE-9 is a technology-specific variant of a more general
     problem, it could be affected by the TECHSPEC discussion point.

CWE-9: J2EE Misconfiguration: Weak Access Permissions

  This is context-specific since the correct permissions/privileges
  can only be defined in terms of the application's own intended
  security policy.

  POSSIBLE CHANGES:

  1) RESTRUCTURING.  CWE-9's parent, "J2EE Environment Issues," is a
     technology-specific grouping node - it's not weakness-focused.  A
     separate parent should be added that is weakness-focused,
     possibly CWE-275 (Permission Issues), although this isn't
     weakness-focused either.  As CWE-9 is currently described, a
     better weakness-focused parent is probably CWE-266 (Incorrect
     Privilege Assignment).

  2) Since CWE-9 is a technology-specific variant of a more general
     problem, it could be affected by the TECHSPEC discussion point.

CWE-589: Call to Limited API

  This is context-specific in that the software might only be intended
  to run on platforms that support the limited API.

  POSSIBLE CHANGES:

  1) No significant changes seem necessary.


CWE-598: Information Leak Through GET Request

  This is context-specific because the notion of "sensitive
  information" can be dependent on the application's own intended
  security policy; some information might be intended to be captured
  in a GET request.

  POSSIBLE CHANGES:

  1) With respect to CONSPEC, no significant changes seem necessary,
     although the description should be clarified.  However, this node
     is a resource-specific variant with many low-level siblings, and
     thus is covered by the RESSPEC discussion point, which might lead
     to significant modifications once RESSPEC has been sufficiently
     evaluated by the researcher community.

CWE-473: PHP External Variable Modification

  This is context-specific because many variables that can be
  modified, are either intended to be modified by the user, or do not
  have security implications.

  POSSIBLE CHANGES:

  1) With respect to CONSPEC, no significant changes seem necessary,
     although minor modifications to the name and description might be
     in order.

[Pascal Meunier-3]

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?
>