[jira] [Updated] (CASSANDRA-12309) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

2018-11-18 Thread C. Scott Andreas (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

C. Scott Andreas updated CASSANDRA-12309:
-
Component/s: Auth

> 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: Sub-task
>  Components: Auth
>Reporter: Eduardo Aguinaga
>Priority: Major
>
> 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
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-12309) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

2016-07-27 Thread Jonathan Ellis (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-12309:
---
Issue Type: Sub-task  (was: Bug)
Parent: CASSANDRA-12334

> 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: Sub-task
>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)


[jira] [Updated] (CASSANDRA-12309) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

2016-07-26 Thread Jeremiah Jordan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremiah Jordan updated CASSANDRA-12309:

Reproduced In: 3.0.5

> 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)


[jira] [Updated] (CASSANDRA-12309) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

2016-07-26 Thread Jeremiah Jordan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremiah Jordan updated CASSANDRA-12309:

Fix Version/s: (was: 3.0.5)

> 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)


[jira] [Updated] (CASSANDRA-12309) Use of Dynamic Class Loading, Use of Externally-Controlled Input to Select Classes or Code

2016-07-26 Thread Eduardo Aguinaga (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eduardo Aguinaga updated CASSANDRA-12309:
-
Description: 
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}

  was:
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.

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}


> 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
> Fix For: 3.0.5
>
>
> 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