« 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 Sean Barnum
::
Rate this Message:
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.
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.
« Return to Thread: Examples of Detailed Changes to Context-Specific CWE Nodes (CONSPEC)
| Free embeddable forum powered by Nabble | Forum Help |
