Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad Implementations of TrustManager/HostnameVerifier not getting detected with generic conditions #12

Open
LordAmit opened this issue Jun 21, 2020 · 0 comments

Comments

@LordAmit
Copy link
Contributor

LordAmit commented Jun 21, 2020

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

Component Version
Java Runtime OpenJDK version 1.8.0_232 64 bit
CG Commit Used 42197b0

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.

Thanks! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant