axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Gainty (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TRANSPORTS-55) Improper Resource Shutdown or Release in BaseUtils.java 246
Date Fri, 09 Jan 2015 00:31:35 GMT

    [ https://issues.apache.org/jira/browse/TRANSPORTS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14270279#comment-14270279
] 

Martin Gainty commented on TRANSPORTS-55:
-----------------------------------------

Parroting the cl-mt guide from Java 
registerAsParallelCapable()  should be called after classloader is created in a static initalizer:

   " If you have a custom class loader with a risk of deadlocking, with the Java SE 7 release,
you can avoid deadlocks by following these rules:

        Ensure that your custom class loader is multithread safe for concurrent class loading.

        a. Decide upon an internal locking scheme. For example, java.lang.ClassLoader uses
a locking scheme based on the requested class name.

        b. Remove all synchronization on the class loader object lock alone.

        c. Ensure that critical sections are safe for multiple threads loading different classes.

        In your custom class loader's static initializer, invoke java.lang.ClassLoader's static
method registerAsParallelCapable(). This registration indicates that all instances of your
custom class loader are multithread safe.

        Check that all class loader classes that this custom class loader extends also invoke
the registerAsParallelCapable() method in their class initializers. Ensure that they are multithread
safe for concurrent class loading.

    If your custom class loader overrides only findClass(String), you do not need further
changes. This is the recommended mechanism to create a custom class loader."

http://stackoverflow.com/questions/18640996/java-deadlock-in-classloaders
http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html

do you want to implement this (so any resource acquired by CL is at least thread-safe)?
Saludos Cordiales,
Martín

> Improper Resource Shutdown or Release in BaseUtils.java 246
> -----------------------------------------------------------
>
>                 Key: TRANSPORTS-55
>                 URL: https://issues.apache.org/jira/browse/TRANSPORTS-55
>             Project: Axis2 Transports
>          Issue Type: Bug
>          Components: Base
>    Affects Versions: 1.0.0
>            Reporter: David Camilo Espitia Manrique
>              Labels: security
>             Fix For: 1.0.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We are currently using "Axis2-transport-base 1.0.0 " and the veracode analysis found
a bug in this class "BaseUtils.java" line 246:
> Type:  Improper Resource Shutdown or Release
> Description:
> The application fails to release (or incorrectly releases) a system resource before it
is made available for re-use. This
> condition often occurs with resources such as database connections or file handles. Most
unreleased resource issues
> result in general software reliability problems, but if an attacker can intentionally
trigger a resource leak, it may be
> possible to launch a denial of service attack by depleting the resource pool.
> Recommendations:
> When a resource is created or allocated, the developer is responsible for properly releasing
the resource as well as
> accounting for all potential paths of expiration or invalidation. Ensure that all code
paths properly release resources



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message