[EXT] CWE Proposal java autoboxing

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[EXT] CWE Proposal java autoboxing

J Harvey
Hello,

I would like to propose a new CWE for the section “Weaknesses in
Software Written in Java”. I have looked through the existing CWE and
think there is space for the proposal (hopefully I have not missed an
existing CWE that covers it). I look forward to your feedback….

Name : Inadvertent use of autoboxing

Description : Use of boxed primitives should be limited to certain
situations such as when calling methods with typed parameters. If used
incorrectly, autoboxing can result in significant performance issues.
 From a security perspective this could potentially impact availability.

Detail : Java has a boxed primitive for each primitive type. For example
long can also be represented with the boxed primitive Long. Collections
cannot be typed by primitives therefore boxed primitives are used in
such situations which is perfectly valid.

Issues arise where boxed primitives are used when not strictly necessary
:

Long count = 0L;

for(long i = 0; i < Integer.MAX_VALUE; i++) {
     count += 1;
}

In the above loop we see that the count variable is declared as a boxed
primitive. This causes autoboxing on the line that increments. This
causes execution to be magnitudes less performant (time and possibly
space) than if primitive long was used to declare the count variable,
possibly resulting in availability issues.

Mode of Introduction : Implementation

Applicable Platforms : Java

Likelihood of Exploit : TBD

Relationships : TBD

Thanks,
Joe
Reply | Threaded
Open this post in threaded view
|

Re: [EXT] CWE Proposal java autoboxing

asummers
Administrator
Joe,

Thanks for reaching out on this and taking the steps to draft up some content. Members of the team will investigate the issue and figure out next steps on our end. I'll be in touch in the near future once we've done that.

Thanks for your support of the CWE project!  

Cheers,
Alec

--
Alec J. Summers
Cyber Solutions Division
Cyber Security Engineer, Lead
(781) 271-6970
 

 
MITRE - Solving Problems for a Safer World
 <https://www.facebook.com/MITREcorp> <https://www.linkedin.com/company/mitre> <https://twitter.com/MITREcorp> <https://www.youtube.com/user/mitrecorp> <https://plus.google.com/+MitreOrgFFRDCs/posts>
 

On 10/14/19, 1:24 PM, "J Harvey" <[hidden email]> wrote:

    Hello,
   
    I would like to propose a new CWE for the section “Weaknesses in
    Software Written in Java”. I have looked through the existing CWE and
    think there is space for the proposal (hopefully I have not missed an
    existing CWE that covers it). I look forward to your feedback….
   
    Name : Inadvertent use of autoboxing
   
    Description : Use of boxed primitives should be limited to certain
    situations such as when calling methods with typed parameters. If used
    incorrectly, autoboxing can result in significant performance issues.
     From a security perspective this could potentially impact availability.
   
    Detail : Java has a boxed primitive for each primitive type. For example
    long can also be represented with the boxed primitive Long. Collections
    cannot be typed by primitives therefore boxed primitives are used in
    such situations which is perfectly valid.
   
    Issues arise where boxed primitives are used when not strictly necessary
    :
   
    Long count = 0L;
   
    for(long i = 0; i < Integer.MAX_VALUE; i++) {
         count += 1;
    }
   
    In the above loop we see that the count variable is declared as a boxed
    primitive. This causes autoboxing on the line that increments. This
    causes execution to be magnitudes less performant (time and possibly
    space) than if primitive long was used to declare the count variable,
    possibly resulting in availability issues.
   
    Mode of Introduction : Implementation
   
    Applicable Platforms : Java
   
    Likelihood of Exploit : TBD
   
    Relationships : TBD
   
    Thanks,
    Joe
   

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [EXT] CWE Proposal java autoboxing

Purohit, Rushi B
Dear CWE Research Community,

Joe Harvey proposed an idea for a new CWE on Java’s use of Autoboxing and Unboxing last week (please see below).  As you are likely aware, since JDK 1.5, conversions from primitive types to corresponding wrapper objects and vice versa can happen automatically by a Java Compiler. This automatic process eliminates the manual step that would otherwise be required by the programmer. However, it does come at a cost of reduce performance. Java’s guideline recommends that Autoboxing and Unboxing shouldn’t be used for scientific computing or other performance critical operations. The CWE team agrees that this issue belongs in CWE. The issue Joe mentioned, as he calls it “Inadvertent Use of Autoboxing”, specifically deals with Java as a language.

Have others in the CWE Community come across the same issue in other programming languages? The CWE team is interested in gathering your feedback as it will allow us to create a proper CWE (either a base level only for Java or a generic CWE with examples of this issue in different programming languages).

We look forward to hearing from you.

As a side note, the CWE team is working on publishing new submission guidelines to the site soon – please keep your eyes out for that.

Regards,
CWE Team

-----Original Message-----
From: Summers, Alec J <[hidden email]>
Sent: Tuesday, October 15, 2019 2:25 PM
To: [hidden email]; CWE Research Discussion <[hidden email]>
Subject: Re: [EXT] CWE Proposal java autoboxing

Joe,

Thanks for reaching out on this and taking the steps to draft up some content. Members of the team will investigate the issue and figure out next steps on our end. I'll be in touch in the near future once we've done that.

Thanks for your support of the CWE project!  

Cheers,
Alec

--
Alec J. Summers
Cyber Solutions Division
Cyber Security Engineer, Lead
(781) 271-6970
 

 
MITRE - Solving Problems for a Safer World
 <https://www.facebook.com/MITREcorp> <https://www.linkedin.com/company/mitre> <https://twitter.com/MITREcorp> <https://www.youtube.com/user/mitrecorp> <https://plus.google.com/+MitreOrgFFRDCs/posts>
 

On 10/14/19, 1:24 PM, "J Harvey" <[hidden email]> wrote:

    Hello,
   
    I would like to propose a new CWE for the section “Weaknesses in
    Software Written in Java”. I have looked through the existing CWE and
    think there is space for the proposal (hopefully I have not missed an
    existing CWE that covers it). I look forward to your feedback….
   
    Name : Inadvertent use of autoboxing
   
    Description : Use of boxed primitives should be limited to certain
    situations such as when calling methods with typed parameters. If used
    incorrectly, autoboxing can result in significant performance issues.
     From a security perspective this could potentially impact availability.
   
    Detail : Java has a boxed primitive for each primitive type. For example
    long can also be represented with the boxed primitive Long. Collections
    cannot be typed by primitives therefore boxed primitives are used in
    such situations which is perfectly valid.
   
    Issues arise where boxed primitives are used when not strictly necessary
    :
   
    Long count = 0L;
   
    for(long i = 0; i < Integer.MAX_VALUE; i++) {
         count += 1;
    }
   
    In the above loop we see that the count variable is declared as a boxed
    primitive. This causes autoboxing on the line that increments. This
    causes execution to be magnitudes less performant (time and possibly
    space) than if primitive long was used to declare the count variable,
    possibly resulting in availability issues.
   
    Mode of Introduction : Implementation
   
    Applicable Platforms : Java
   
    Likelihood of Exploit : TBD
   
    Relationships : TBD
   
    Thanks,
    Joe
   

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [EXT] CWE Proposal java autoboxing

J Harvey
CWE Team, thanks for your response on this.

Once we have a view from others on the impact on other languages then I
would be more than happy to help out by drafting a detailed/complete CWE
for you. Just let me know if you want me to do that...

Thanks,
Joe

On 2019-10-24 19:36, Purohit, Rushi B wrote:

> Dear CWE Research Community,
>
> Joe Harvey proposed an idea for a new CWE on Java’s use of Autoboxing
> and Unboxing last week (please see below).  As you are likely aware,
> since JDK 1.5, conversions from primitive types to corresponding
> wrapper objects and vice versa can happen automatically by a Java
> Compiler. This automatic process eliminates the manual step that would
> otherwise be required by the programmer. However, it does come at a
> cost of reduce performance. Java’s guideline recommends that
> Autoboxing and Unboxing shouldn’t be used for scientific computing or
> other performance critical operations. The CWE team agrees that this
> issue belongs in CWE. The issue Joe mentioned, as he calls it
> “Inadvertent Use of Autoboxing”, specifically deals with Java as a
> language.
>
> Have others in the CWE Community come across the same issue in other
> programming languages? The CWE team is interested in gathering your
> feedback as it will allow us to create a proper CWE (either a base
> level only for Java or a generic CWE with examples of this issue in
> different programming languages).
>
> We look forward to hearing from you.
>
> As a side note, the CWE team is working on publishing new submission
> guidelines to the site soon – please keep your eyes out for that.
>
> Regards,
> CWE Team
>
> -----Original Message-----
> From: Summers, Alec J <[hidden email]>
> Sent: Tuesday, October 15, 2019 2:25 PM
> To: [hidden email]; CWE Research Discussion
> <[hidden email]>
> Subject: Re: [EXT] CWE Proposal java autoboxing
>
> Joe,
>
> Thanks for reaching out on this and taking the steps to draft up some
> content. Members of the team will investigate the issue and figure out
> next steps on our end. I'll be in touch in the near future once we've
> done that.
>
> Thanks for your support of the CWE project!
>
> Cheers,
> Alec
>
> --
> Alec J. Summers
> Cyber Solutions Division
> Cyber Security Engineer, Lead
> (781) 271-6970
>
>
>
> MITRE - Solving Problems for a Safer World
>  <https://www.facebook.com/MITREcorp>
> <https://www.linkedin.com/company/mitre>
> <https://twitter.com/MITREcorp>
> <https://www.youtube.com/user/mitrecorp>
> <https://plus.google.com/+MitreOrgFFRDCs/posts>
>
>
> On 10/14/19, 1:24 PM, "J Harvey" <[hidden email]> wrote:
>
>     Hello,
>
>     I would like to propose a new CWE for the section “Weaknesses in
>     Software Written in Java”. I have looked through the existing CWE
> and
>     think there is space for the proposal (hopefully I have not missed
> an
>     existing CWE that covers it). I look forward to your feedback….
>
>     Name : Inadvertent use of autoboxing
>
>     Description : Use of boxed primitives should be limited to certain
>     situations such as when calling methods with typed parameters. If
> used
>     incorrectly, autoboxing can result in significant performance
> issues.
>      From a security perspective this could potentially impact
> availability.
>
>     Detail : Java has a boxed primitive for each primitive type. For
> example
>     long can also be represented with the boxed primitive Long.
> Collections
>     cannot be typed by primitives therefore boxed primitives are used
> in
>     such situations which is perfectly valid.
>
>     Issues arise where boxed primitives are used when not strictly
> necessary
>     :
>
>     Long count = 0L;
>
>     for(long i = 0; i < Integer.MAX_VALUE; i++) {
>          count += 1;
>     }
>
>     In the above loop we see that the count variable is declared as a
> boxed
>     primitive. This causes autoboxing on the line that increments. This
>     causes execution to be magnitudes less performant (time and
> possibly
>     space) than if primitive long was used to declare the count
> variable,
>     possibly resulting in availability issues.
>
>     Mode of Introduction : Implementation
>
>     Applicable Platforms : Java
>
>     Likelihood of Exploit : TBD
>
>     Relationships : TBD
>
>     Thanks,
>     Joe