cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eduardo Aguinaga (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12309) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code
Date Wed, 27 Jul 2016 08:07:20 GMT

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

Eduardo Aguinaga commented on CASSANDRA-12309:
----------------------------------------------

I know that its done in many places. I have identified many more security issues than I have
had an opportunity to log (as of this writing). More to come.
Calling the use of dynamic class loading a feature can be misguided. It can be leveraged by
a hacker to make Cassandra do things that you do not want it to do. It may never be leveraged
as a vulnerability, but it exists.
My job was to identify software vulnerabilities in Cassandra. If your stance is to call a
vulnerability a feature, so be it. I will report this as your response.
Ed



 		 	   		  


> Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or
Code
> ------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-12309
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12309
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Eduardo Aguinaga
>
> Overview:
> In May through June of 2016 a static analysis was performed on version 3.0.5 of the Cassandra
source code. The analysis included an automated analysis using HP Fortify v4.21 SCA and a
manual analysis utilizing SciTools Understand v4. The results of that analysis includes the
issue below.
> Issue:
> Dynamically loaded code has the potential to be malicious. The application uses external
input to select which classes or code to use, but it does not sufficiently prevent the input
from selecting improper classes or code.
> The snippet below shows the issue on line 588 and the method returns a new instance on
line 594 or 598.
> CqlConfigHelper.java, lines 584-605:
> {code:java}
> 584 private static AuthProvider getClientAuthProvider(String factoryClassName, Configuration
conf)
> 585 {
> 586     try
> 587     {
> 588         Class<?> c = Class.forName(factoryClassName);
> 589         if (PlainTextAuthProvider.class.equals(c))
> 590         {
> 591             String username = getStringSetting(USERNAME, conf).or("");
> 592             String password = getStringSetting(PASSWORD, conf).or("");
> 593             return (AuthProvider) c.getConstructor(String.class, String.class)
> 594                     .newInstance(username, password);
> 595         }
> 596         else
> 597         {
> 598             return (AuthProvider) c.newInstance();
> 599         }
> 600     }
> 601     catch (Exception e)
> 602     {
> 603         throw new RuntimeException("Failed to instantiate auth provider:" + factoryClassName,
e);
> 604     }
> 605 }
> {code}



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

Mime
View raw message