My team is conducting academic research on Java Cryptography API based misuse using your tool. We found that we could not detect some potential cryptographic misuses.
We believe this may be due to underlying implementation or design gaps. Each cryptographic vulnerability was generated as a barebone Java project that only contained a single vulnerability in the main function and used up to two java source files. A jar was made which was then scanned using CryptoGuard.
Additionally, all cryptographic API calls were from Java Cryptographic Architecture (JCA).
Environment
Component
Version
Java Runtime
OpenJDK version 1.8.0_232 64 bit
CG Commit Used
42197b03f65d9b58abc1c9f49eb427f140393ede
Problem
Attempting to use an insecure validation of an overridden checkServerTrusted method that is created within an anonymous inner class object created from an empty abstract class which implements the X509TrustManager interface from JCA, which we believe is due to not detecting security exceptions thrown under impossible conditions; e.g.,
if(!(true || arg0== null || arg1 == null)) throw new CertificateException();
public abstract class BareboneTrustManagerExt implements javax.net.ssl.X509TrustManager{
}
public class BareboneTrustManagerConditional {
static final X509Certificate[] EMPTY_X509CERTIFICATE_ARRAY = new X509Certificate[] {};
public static void main(String[] args) {
TrustManager[] trustAll = new TrustManager[] {
new BareboneTrustManagerExt() {
@java.lang.Override
public void checkClientTrusted(java.security.cert.X509Certificate[] arg0, java.lang.String arg1)
throws java.security.cert.CertificateException {
if(!(true||arg0 == null||arg1 == null)){
throw new java.security.cert.CertificateException();
}
}
@java.lang.Override
public void checkServerTrusted(java.security.cert.X509Certificate[] arg0, java.lang.String arg1)
throws java.security.cert.CertificateException {
if(!(true||arg0 == null||arg1 == null)){
throw new java.security.cert.CertificateException();
}
}
@Override
public X509Certificate[] getAcceptedIssuers() {
for(int i = 0; i<100; i++){
if (i==50)
return EMPTY_X509CERTIFICATE_ARRAY;;
}
return EMPTY_X509CERTIFICATE_ARRAY;
}
}
};
SSLContext context;
try {
context = SSLContext.getInstance("TLS");
context.init(null, trustAll, new SecureRandom());
} catch (NoSuchAlgorithmException e) {
// TODO Auto-generated catch block
// e.printStackTrace();
} catch (KeyManagementException e) {
// TODO Auto-generated catch block
// e.printStackTrace();
}
System.out.println("Hello World 8.6");
}
}
Attempting to use an insecure analysis of vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an empty interface that implements the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g.,
if(true || session == null) return true; return false;
public interface ABadHostNameVerifier extends HostnameVerifier {
public boolean verify(String hostname, SSLSession session);
}
public class BadHostName{
public static void main(String[] args) {
new ABadHostNameVerifier(){
@Override
public boolean verify(String hostname, SSLSession session) {
if(true || session == null){
return true;
}
return false;
}
};
}
}
Attempting to use a vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an abstract class that extends the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g.,
if(true || session == null) return true; return false;
public abstract class ABadHostNameVerifier implements HostnameVerifier {
}
public class BadHostName{
public static void main(String[] args) {
new ABadHostNameVerifier(){
@Override
public boolean verify(String hostname, SSLSession session) {
if(true || session == null){
return true;
}
return false;
}
};
}
}
Please let me know if you need any additional information (e.g., logs from our side) in fixing these issues.
Hi,
My team is conducting academic research on Java Cryptography API based misuse using your tool. We found that we could not detect some potential cryptographic misuses.
We believe this may be due to underlying implementation or design gaps. Each cryptographic vulnerability was generated as a barebone Java project that only contained a single vulnerability in the main function and used up to two java source files. A jar was made which was then scanned using CryptoGuard. Additionally, all cryptographic API calls were from Java Cryptographic Architecture (JCA).
Environment
Problem
Attempting to use an insecure validation of an overridden checkServerTrusted method that is created within an anonymous inner class object created from an empty abstract class which implements the X509TrustManager interface from JCA, which we believe is due to not detecting security exceptions thrown under impossible conditions; e.g.,
if(!(true || arg0== null || arg1 == null)) throw new CertificateException();Attempting to use an insecure analysis of vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an empty interface that implements the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g.,
if(true || session == null) return true; return false;Attempting to use a vulnerable hostname verification, i.e., the verify() method within an anonymous inner class object that is created from an abstract class that extends the HostnameVerifier interface from JCA, which we believe is due to the failure to detect an always true condition block that returns true; e.g.,
if(true || session == null) return true; return false;Please let me know if you need any additional information (e.g., logs from our side) in fixing these issues.
Thanks! :)