Suggestions for Changes to CWE-581 (UNCLASSIFIED)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Suggestions for Changes to CWE-581 (UNCLASSIFIED)

Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
CLASSIFICATION: UNCLASSIFIED

I had some suggestions for CWE-581:

BLUF: I recommend simplifying the name, adding additional languages, and
providing a simple example.

Suggested Name (make more generic): "Just One of Equals and Hashcode
Defined"
The existing preamble "Object Model Violation" is unique. For other title
preambles, such as "Struts", "J2EE Bad Practices", or "EJB Bad Practices",
there are multiple CWEs that have the preamble. Having a single "Object
Model Violation" preamble in the entire CWE seems inconsistent. If it's to
be kept, would it not be more meaningful to include it on CWEs like 568 and
580 as well?

Description Summary:
The object does not guarantee the maintenance of equal hashcodes for equal
objects.

Extended Description:
Objects are expected to obey a number of invariants related to equality. One
of these invariants is that equal objects must have equal hashcodes. In
other words, if a.equals(b) == true then a.hashCode() == b.hashCode().

Languages:
Java
.NET
Ruby

Consequence: Integrity
Technical Impact: Other
If this invariant is not upheld, it is likely to cause trouble if objects of
this class are stored in a collection. If the objects of the class in
question are used as a key in a Hashtable or if they are inserted into a Map
or Set, it is critical that equal objects have equal hashcodes.

Demonstrative Examples:
The following code inserts two items that evaluate as equal, but have
different hashes. Calls to set functions that rely on hash comparison (such
as Distinct()) identify the objects as different.
--BEGIN BAD CODE LANGUAGE=C#--
public class Hashable
{
    public int i { get; set; }
    public Hashable(int input)
    {
        i = input;
    }
    public override bool Equals(object obj)
    {
        return this.i == (obj as Hashable).i;
    }
    static void Main(string[] args)
    {
        List<Hashable> list = new List<Hashable>();
        list.Add(new Hashable(1));
        list.Add(new Hashable(1));
        //list.Distinct() will return both records, even though they
evaluate as equal.
    }
}
--END BAD CODE--
The developer has not ensured that the Equals and GetHashCode functions are
both overridden, which can cause unexpected behavior later in the program.

Potential Mitigations:

Phase: Requirements
Strategy: Language Selection
Use a language that does not provide hashable generic objects, and avoid
libraries that provide such capabilities. Be wary that interfaces to other
native code may still cause problems.

Phase: Implementation
Both Equals() and Hashcode() should be defined.

References: https://msdn.microsoft.com/en-us/library/ms182358.aspx

Side question: Is there a repository somewhere so that we can submit our
change requests with pull requests, merges, or in another standard format?

Jon Hood
(256) 876-0326
CLASSIFICATION: UNCLASSIFIED

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Suggestions for Changes to CWE-581 (UNCLASSIFIED)

Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
CLASSIFICATION: UNCLASSIFIED

As tacky as it is to reply to your own message, I do have another recommendation for a similar CWE:

Title: "Equals not defined as FALSE for null input."

This has two potential software weaknesses that are checked for:
1. A developer checking for an uninstantiated Object o may inadvertently write o.Equals(null) to perform the check. This can cause a null pointer dereference (CWE-476) when o is null.
2. A developer overrides the Equals operator but does not include a null object check, which must always return false. Equality invariants, such as the requirement for an instantiated object not to equal null, must be preserved. In other words, if Object o is defined, o.Equals(null) must always be false.

The new CWE would be a child of CWE-171 or CWE-697

If someone thinks that this would be a meaningful addition, please let me know and I'll write up a more full description.

Jon Hood
(256) 876-0326


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
Sent: Thursday, May 11, 2017 8:42 AM
To: [hidden email]
Subject: [Non-DoD Source] Suggestions for Changes to CWE-581 (UNCLASSIFIED)

All active links contained in this email were disabled.  Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.  




----

CLASSIFICATION: UNCLASSIFIED

I had some suggestions for CWE-581:

BLUF: I recommend simplifying the name, adding additional languages, and
providing a simple example.

Suggested Name (make more generic): "Just One of Equals and Hashcode
Defined"
The existing preamble "Object Model Violation" is unique. For other title
preambles, such as "Struts", "J2EE Bad Practices", or "EJB Bad Practices",
there are multiple CWEs that have the preamble. Having a single "Object
Model Violation" preamble in the entire CWE seems inconsistent. If it's to
be kept, would it not be more meaningful to include it on CWEs like 568 and
580 as well?

Description Summary:
The object does not guarantee the maintenance of equal hashcodes for equal
objects.

Extended Description:
Objects are expected to obey a number of invariants related to equality. One
of these invariants is that equal objects must have equal hashcodes. In
other words, if a.equals(b) == true then a.hashCode() == b.hashCode().

Languages:
Java
.NET
Ruby

Consequence: Integrity
Technical Impact: Other
If this invariant is not upheld, it is likely to cause trouble if objects of
this class are stored in a collection. If the objects of the class in
question are used as a key in a Hashtable or if they are inserted into a Map
or Set, it is critical that equal objects have equal hashcodes.

Demonstrative Examples:
The following code inserts two items that evaluate as equal, but have
different hashes. Calls to set functions that rely on hash comparison (such
as Distinct()) identify the objects as different.
--BEGIN BAD CODE LANGUAGE=C#--
public class Hashable
{
    public int i { get; set; }
    public Hashable(int input)
    {
        i = input;
    }
    public override bool Equals(object obj)
    {
        return this.i == (obj as Hashable).i;
    }
    static void Main(string[] args)
    {
        List<Hashable> list = new List<Hashable>();
        list.Add(new Hashable(1));
        list.Add(new Hashable(1));
        //list.Distinct() will return both records, even though they
evaluate as equal.
    }
}
--END BAD CODE--
The developer has not ensured that the Equals and GetHashCode functions are
both overridden, which can cause unexpected behavior later in the program.

Potential Mitigations:

Phase: Requirements
Strategy: Language Selection
Use a language that does not provide hashable generic objects, and avoid
libraries that provide such capabilities. Be wary that interfaces to other
native code may still cause problems.

Phase: Implementation
Both Equals() and Hashcode() should be defined.

References: Caution-https://msdn.microsoft.com/en-us/library/ms182358.aspx

Side question: Is there a repository somewhere so that we can submit our
change requests with pull requests, merges, or in another standard format?

Jon Hood
(256) 876-0326
CLASSIFICATION: UNCLASSIFIED

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
CLASSIFICATION: UNCLASSIFIED

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Suggestions for Changes to CWE-581 (UNCLASSIFIED)

Andrew Buttner
Administrator
In reply to this post by Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
Jon,

Thank you for submitting these changes. We will work to get these updates into the next release of CWE. At first glance, I agree with the title change as it makes this CWE simpler and more consistent. I suggest a slight tweak to your proposed description ... "The software does not guarantee that two equal objects will generate the same hashcode."

Related to your side question, there unfortunately is not currently any place to submit change requests beyond this mailing list. If there is enough demand, this could be something we look to add in the future.

Thanks
Drew


> -----Original Message-----
> From: [hidden email] [mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US)
> Sent: Thursday, May 11, 2017 9:42 AM
> To: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: Suggestions for Changes to CWE-581 (UNCLASSIFIED)
>
> CLASSIFICATION: UNCLASSIFIED
>
> I had some suggestions for CWE-581:
>
> BLUF: I recommend simplifying the name, adding additional languages, and
> providing a simple example.
>
> Suggested Name (make more generic): "Just One of Equals and Hashcode
> Defined"
> The existing preamble "Object Model Violation" is unique. For other title
> preambles, such as "Struts", "J2EE Bad Practices", or "EJB Bad Practices",
> there are multiple CWEs that have the preamble. Having a single "Object
> Model Violation" preamble in the entire CWE seems inconsistent. If it's to
> be kept, would it not be more meaningful to include it on CWEs like 568 and
> 580 as well?
>
> Description Summary:
> The object does not guarantee the maintenance of equal hashcodes for
> equal
> objects.
>
> Extended Description:
> Objects are expected to obey a number of invariants related to equality. One
> of these invariants is that equal objects must have equal hashcodes. In
> other words, if a.equals(b) == true then a.hashCode() == b.hashCode().
>
> Languages:
> Java
> .NET
> Ruby
>
> Consequence: Integrity
> Technical Impact: Other
> If this invariant is not upheld, it is likely to cause trouble if objects of
> this class are stored in a collection. If the objects of the class in
> question are used as a key in a Hashtable or if they are inserted into a Map
> or Set, it is critical that equal objects have equal hashcodes.
>
> Demonstrative Examples:
> The following code inserts two items that evaluate as equal, but have
> different hashes. Calls to set functions that rely on hash comparison (such
> as Distinct()) identify the objects as different.
> --BEGIN BAD CODE LANGUAGE=C#--
> public class Hashable
> {
>     public int i { get; set; }
>     public Hashable(int input)
>     {
>         i = input;
>     }
>     public override bool Equals(object obj)
>     {
>         return this.i == (obj as Hashable).i;
>     }
>     static void Main(string[] args)
>     {
>         List<Hashable> list = new List<Hashable>();
>         list.Add(new Hashable(1));
>         list.Add(new Hashable(1));
>         //list.Distinct() will return both records, even though they
> evaluate as equal.
>     }
> }
> --END BAD CODE--
> The developer has not ensured that the Equals and GetHashCode functions
> are
> both overridden, which can cause unexpected behavior later in the program.
>
> Potential Mitigations:
>
> Phase: Requirements
> Strategy: Language Selection
> Use a language that does not provide hashable generic objects, and avoid
> libraries that provide such capabilities. Be wary that interfaces to other
> native code may still cause problems.
>
> Phase: Implementation
> Both Equals() and Hashcode() should be defined.
>
> References: https://msdn.microsoft.com/en-us/library/ms182358.aspx
>
> Side question: Is there a repository somewhere so that we can submit our
> change requests with pull requests, merges, or in another standard format?
>
> Jon Hood
> (256) 876-0326
> CLASSIFICATION: UNCLASSIFIED
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Suggestions for Changes to CWE-581 (UNCLASSIFIED)

Andrew Buttner
Administrator
In reply to this post by Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
Jon,

Do you have any additional references for this type of issue?

In your first item, if o is null, wouldn't a null pointer dereference always occur for o.Equals() regardless of how Equals() is implemented?  This is just an instance of CWE-476, right?

For the second item, is it the individual language that defines that Equals() should return false for null?

Thanks
Drew



> -----Original Message-----
> From: [hidden email] [mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US)
> Sent: Thursday, May 11, 2017 3:06 PM
> To: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: RE: [Non-DoD Source] Suggestions for Changes to CWE-581
> (UNCLASSIFIED)
>
> CLASSIFICATION: UNCLASSIFIED
>
> As tacky as it is to reply to your own message, I do have another
> recommendation for a similar CWE:
>
> Title: "Equals not defined as FALSE for null input."
>
> This has two potential software weaknesses that are checked for:
> 1. A developer checking for an uninstantiated Object o may inadvertently
> write o.Equals(null) to perform the check. This can cause a null pointer
> dereference (CWE-476) when o is null.
> 2. A developer overrides the Equals operator but does not include a null
> object check, which must always return false. Equality invariants, such as the
> requirement for an instantiated object not to equal null, must be preserved.
> In other words, if Object o is defined, o.Equals(null) must always be false.
>
> The new CWE would be a child of CWE-171 or CWE-697
>
> If someone thinks that this would be a meaningful addition, please let me
> know and I'll write up a more full description.
>
> Jon Hood
> (256) 876-0326
>
>
> -----Original Message-----
> From: [hidden email] [mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US)
> Sent: Thursday, May 11, 2017 8:42 AM
> To: [hidden email]
> Subject: [Non-DoD Source] Suggestions for Changes to CWE-581
> (UNCLASSIFIED)
>
> All active links contained in this email were disabled.  Please verify the
> identity of the sender, and confirm the authenticity of all links contained
> within the message prior to copying and pasting the address to a Web
> browser.
>
>
>
>
> ----
>
> CLASSIFICATION: UNCLASSIFIED
>
> I had some suggestions for CWE-581:
>
> BLUF: I recommend simplifying the name, adding additional languages, and
> providing a simple example.
>
> Suggested Name (make more generic): "Just One of Equals and Hashcode
> Defined"
> The existing preamble "Object Model Violation" is unique. For other title
> preambles, such as "Struts", "J2EE Bad Practices", or "EJB Bad Practices",
> there are multiple CWEs that have the preamble. Having a single "Object
> Model Violation" preamble in the entire CWE seems inconsistent. If it's to be
> kept, would it not be more meaningful to include it on CWEs like 568 and
> 580 as well?
>
> Description Summary:
> The object does not guarantee the maintenance of equal hashcodes for
> equal objects.
>
> Extended Description:
> Objects are expected to obey a number of invariants related to equality. One
> of these invariants is that equal objects must have equal hashcodes. In other
> words, if a.equals(b) == true then a.hashCode() == b.hashCode().
>
> Languages:
> Java
> .NET
> Ruby
>
> Consequence: Integrity
> Technical Impact: Other
> If this invariant is not upheld, it is likely to cause trouble if objects of this class
> are stored in a collection. If the objects of the class in question are used as a
> key in a Hashtable or if they are inserted into a Map or Set, it is critical that
> equal objects have equal hashcodes.
>
> Demonstrative Examples:
> The following code inserts two items that evaluate as equal, but have
> different hashes. Calls to set functions that rely on hash comparison (such as
> Distinct()) identify the objects as different.
> --BEGIN BAD CODE LANGUAGE=C#--
> public class Hashable
> {
>     public int i { get; set; }
>     public Hashable(int input)
>     {
>         i = input;
>     }
>     public override bool Equals(object obj)
>     {
>         return this.i == (obj as Hashable).i;
>     }
>     static void Main(string[] args)
>     {
>         List<Hashable> list = new List<Hashable>();
>         list.Add(new Hashable(1));
>         list.Add(new Hashable(1));
>         //list.Distinct() will return both records, even though they evaluate as
> equal.
>     }
> }
> --END BAD CODE--
> The developer has not ensured that the Equals and GetHashCode functions
> are both overridden, which can cause unexpected behavior later in the
> program.
>
> Potential Mitigations:
>
> Phase: Requirements
> Strategy: Language Selection
> Use a language that does not provide hashable generic objects, and avoid
> libraries that provide such capabilities. Be wary that interfaces to other native
> code may still cause problems.
>
> Phase: Implementation
> Both Equals() and Hashcode() should be defined.
>
> References: Caution-https://msdn.microsoft.com/en-
> us/library/ms182358.aspx
>
> Side question: Is there a repository somewhere so that we can submit our
> change requests with pull requests, merges, or in another standard format?
>
> Jon Hood
> (256) 876-0326
> CLASSIFICATION: UNCLASSIFIED
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].
> CLASSIFICATION: UNCLASSIFIED
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] Suggestions for Changes to CWE-581 (UNCLASSIFIED)

Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
CLASSIFICATION: UNCLASSIFIED

Thanks for the feedback! There should indeed be an extra null check in the
Equals() override:

public override bool Equals(object obj)
{
  If (obj == null) return false;
  return this.i == (obj as Hashable).i;
}

However, the issue being illustrated is not the null dereference - it's the
lack of overriding Hashcode() (in a language other than Java), which must
also be defined. The equality semantics are that two objects that evaluate
as equal must also return the same hashcode (further reference:
https://msdn.microsoft.com/en-us/library/system.object.gethashcode(v=vs.110)
.aspx "If you override the GetHashCode method, you should also override
Equals, and vice versa. If your overridden Equals method returns true when
two objects are tested for equality, your overridden GetHashCode method must
return the same value for the two objects."). The example is meant to show
what can happen (the failure of the Distinct() function) when this tautology
does not hold. I'd be fine if you want to add the null pointer check into
the example to avoid confusion with CWE-476.

For the references regarding object.Equals(null) returning false, I'll
reference
https://www.securecoding.cert.org/confluence/display/java/MET08-J.+Preserve+
the+equality+contract+when+overriding+the+equals%28%29+method for java
("5.For any non-null reference value x, x.equals(null) must return false.")
and for C#, I'll reference
https://msdn.microsoft.com/en-us/library/336aedhh(v=vs.100).aspx which has
pretty much the same Equals contract language as the Java reference.

Jon Hood
(256) 876-0326


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Buttner, Drew
Sent: Tuesday, June 06, 2017 10:44 AM
To: cwe-research-list CWE Research Discussion
<[hidden email]>
Subject: RE: [Non-DoD Source] Suggestions for Changes to CWE-581
(UNCLASSIFIED)

Jon,

Do you have any additional references for this type of issue?

In your first item, if o is null, wouldn't a null pointer dereference always
occur for o.Equals() regardless of how Equals() is implemented?  This is
just an instance of CWE-476, right?

For the second item, is it the individual language that defines that
Equals() should return false for null?

Thanks
Drew



> -----Original Message-----
> From: [hidden email]
> [mailto:owner-cwe-research- [hidden email]] On Behalf Of Hood,
> Jonathan W CTR USARMY RDECOM AMRDEC (US)
> Sent: Thursday, May 11, 2017 3:06 PM
> To: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: RE: [Non-DoD Source] Suggestions for Changes to CWE-581
> (UNCLASSIFIED)
>
> CLASSIFICATION: UNCLASSIFIED
>
> As tacky as it is to reply to your own message, I do have another
> recommendation for a similar CWE:
>
> Title: "Equals not defined as FALSE for null input."
>
> This has two potential software weaknesses that are checked for:
> 1. A developer checking for an uninstantiated Object o may
> inadvertently write o.Equals(null) to perform the check. This can
> cause a null pointer dereference (CWE-476) when o is null.
> 2. A developer overrides the Equals operator but does not include a
> null object check, which must always return false. Equality
> invariants, such as the requirement for an instantiated object not to
equal null, must be preserved.
> In other words, if Object o is defined, o.Equals(null) must always be
false.

>
> The new CWE would be a child of CWE-171 or CWE-697
>
> If someone thinks that this would be a meaningful addition, please let
> me know and I'll write up a more full description.
>
> Jon Hood
> (256) 876-0326
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:owner-cwe-research- [hidden email]] On Behalf Of Hood,
> Jonathan W CTR USARMY RDECOM AMRDEC (US)
> Sent: Thursday, May 11, 2017 8:42 AM
> To: [hidden email]
> Subject: [Non-DoD Source] Suggestions for Changes to CWE-581
> (UNCLASSIFIED)
>
> All active links contained in this email were disabled.  Please verify
> the identity of the sender, and confirm the authenticity of all links
> contained within the message prior to copying and pasting the address
> to a Web browser.
>
>
>
>
> ----
>
> CLASSIFICATION: UNCLASSIFIED
>
> I had some suggestions for CWE-581:
>
> BLUF: I recommend simplifying the name, adding additional languages,
> and providing a simple example.
>
> Suggested Name (make more generic): "Just One of Equals and Hashcode
> Defined"
> The existing preamble "Object Model Violation" is unique. For other
> title preambles, such as "Struts", "J2EE Bad Practices", or "EJB Bad
> Practices", there are multiple CWEs that have the preamble. Having a
> single "Object Model Violation" preamble in the entire CWE seems
> inconsistent. If it's to be kept, would it not be more meaningful to
> include it on CWEs like 568 and
> 580 as well?
>
> Description Summary:
> The object does not guarantee the maintenance of equal hashcodes for
> equal objects.
>
> Extended Description:
> Objects are expected to obey a number of invariants related to
> equality. One of these invariants is that equal objects must have
> equal hashcodes. In other words, if a.equals(b) == true then a.hashCode()
== b.hashCode().

>
> Languages:
> Java
> .NET
> Ruby
>
> Consequence: Integrity
> Technical Impact: Other
> If this invariant is not upheld, it is likely to cause trouble if
> objects of this class are stored in a collection. If the objects of
> the class in question are used as a key in a Hashtable or if they are
> inserted into a Map or Set, it is critical that equal objects have equal
hashcodes.

>
> Demonstrative Examples:
> The following code inserts two items that evaluate as equal, but have
> different hashes. Calls to set functions that rely on hash comparison
> (such as
> Distinct()) identify the objects as different.
> --BEGIN BAD CODE LANGUAGE=C#--
> public class Hashable
> {
>     public int i { get; set; }
>     public Hashable(int input)
>     {
>         i = input;
>     }
>     public override bool Equals(object obj)
>     {
>         return this.i == (obj as Hashable).i;
>     }
>     static void Main(string[] args)
>     {
>         List<Hashable> list = new List<Hashable>();
>         list.Add(new Hashable(1));
>         list.Add(new Hashable(1));
>         //list.Distinct() will return both records, even though they
> evaluate as equal.
>     }
> }
> --END BAD CODE--
> The developer has not ensured that the Equals and GetHashCode
> functions are both overridden, which can cause unexpected behavior
> later in the program.
>
> Potential Mitigations:
>
> Phase: Requirements
> Strategy: Language Selection
> Use a language that does not provide hashable generic objects, and
> avoid libraries that provide such capabilities. Be wary that
> interfaces to other native code may still cause problems.
>
> Phase: Implementation
> Both Equals() and Hashcode() should be defined.
>
> References: Caution-https://msdn.microsoft.com/en-
> us/library/ms182358.aspx
>
> Side question: Is there a repository somewhere so that we can submit
> our change requests with pull requests, merges, or in another standard
format?

>
> Jon Hood
> (256) 876-0326
> CLASSIFICATION: UNCLASSIFIED
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].
> CLASSIFICATION: UNCLASSIFIED
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].
To unsubscribe, send an email message to [hidden email] with
SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
difficulties, write to [hidden email].
CLASSIFICATION: UNCLASSIFIED

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Non-DoD Source] RE: Suggestions for Changes to CWE-581 (UNCLASSIFIED)

Hood, Jonathan W CTR USARMY RDECOM AMRDEC (US)
In reply to this post by Andrew Buttner
CLASSIFICATION: UNCLASSIFIED

I like the tweakage; thanks!

Jon Hood
(256) 876-0326


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Buttner, Drew
Sent: Tuesday, June 06, 2017 9:57 AM
To: cwe-research-list CWE Research Discussion
<[hidden email]>
Subject: [Non-DoD Source] RE: Suggestions for Changes to CWE-581
(UNCLASSIFIED)

All active links contained in this email were disabled.  Please verify the
identity of the sender, and confirm the authenticity of all links contained
within the message prior to copying and pasting the address to a Web
browser.  




----

Jon,

Thank you for submitting these changes. We will work to get these updates
into the next release of CWE. At first glance, I agree with the title change
as it makes this CWE simpler and more consistent. I suggest a slight tweak
to your proposed description ... "The software does not guarantee that two
equal objects will generate the same hashcode."

Related to your side question, there unfortunately is not currently any
place to submit change requests beyond this mailing list. If there is enough
demand, this could be something we look to add in the future.

Thanks
Drew


> -----Original Message-----
> From: [hidden email]
> [Caution-mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Hood, Jonathan W CTR USARMY RDECOM
> AMRDEC (US)
> Sent: Thursday, May 11, 2017 9:42 AM
> To: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
> Subject: Suggestions for Changes to CWE-581 (UNCLASSIFIED)
>
> CLASSIFICATION: UNCLASSIFIED
>
> I had some suggestions for CWE-581:
>
> BLUF: I recommend simplifying the name, adding additional languages,
> and providing a simple example.
>
> Suggested Name (make more generic): "Just One of Equals and Hashcode
> Defined"
> The existing preamble "Object Model Violation" is unique. For other
> title preambles, such as "Struts", "J2EE Bad Practices", or "EJB Bad
> Practices", there are multiple CWEs that have the preamble. Having a
> single "Object Model Violation" preamble in the entire CWE seems
> inconsistent. If it's to be kept, would it not be more meaningful to
> include it on CWEs like 568 and
> 580 as well?
>
> Description Summary:
> The object does not guarantee the maintenance of equal hashcodes for
> equal objects.
>
> Extended Description:
> Objects are expected to obey a number of invariants related to
> equality. One of these invariants is that equal objects must have
> equal hashcodes. In other words, if a.equals(b) == true then a.hashCode()
== b.hashCode().

>
> Languages:
> Java
> .NET
> Ruby
>
> Consequence: Integrity
> Technical Impact: Other
> If this invariant is not upheld, it is likely to cause trouble if
> objects of this class are stored in a collection. If the objects of
> the class in question are used as a key in a Hashtable or if they are
> inserted into a Map or Set, it is critical that equal objects have equal
hashcodes.

>
> Demonstrative Examples:
> The following code inserts two items that evaluate as equal, but have
> different hashes. Calls to set functions that rely on hash comparison
> (such as Distinct()) identify the objects as different.
> --BEGIN BAD CODE LANGUAGE=C#--
> public class Hashable
> {
>     public int i { get; set; }
>     public Hashable(int input)
>     {
>         i = input;
>     }
>     public override bool Equals(object obj)
>     {
>         return this.i == (obj as Hashable).i;
>     }
>     static void Main(string[] args)
>     {
>         List<Hashable> list = new List<Hashable>();
>         list.Add(new Hashable(1));
>         list.Add(new Hashable(1));
>         //list.Distinct() will return both records, even though they
> evaluate as equal.
>     }
> }
> --END BAD CODE--
> The developer has not ensured that the Equals and GetHashCode
> functions are both overridden, which can cause unexpected behavior
> later in the program.
>
> Potential Mitigations:
>
> Phase: Requirements
> Strategy: Language Selection
> Use a language that does not provide hashable generic objects, and
> avoid libraries that provide such capabilities. Be wary that
> interfaces to other native code may still cause problems.
>
> Phase: Implementation
> Both Equals() and Hashcode() should be defined.
>
> References:
> Caution-https://msdn.microsoft.com/en-us/library/ms182358.aspx
>
> Side question: Is there a repository somewhere so that we can submit
> our change requests with pull requests, merges, or in another standard
format?
>
> Jon Hood
> (256) 876-0326
> CLASSIFICATION: UNCLASSIFIED
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have
difficulties, write to [hidden email].
CLASSIFICATION: UNCLASSIFIED

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

smime.p7s (7K) Download Attachment
Loading...