Unsafe SSL configurations have been the cause of quite a few CVEs . I wanted to share a couple I ran into when investigating past CVEs. I don't expect this query to find all the cases listed below, but they might be a good starting point for more queries in this area.

CVE-2020-1929 apache/beam@a7dd23d

CVE-2018-17187 apache/qpid-proton-j@0cb8ca0

CVE-2018-8034 apache/tomcat@2835bb4

CVE-2018-10936 pgjdbc/pgjdbc@cdeeaca

CVE-2018-11087 spring-projects/spring-amqp@444b74e

CVE-2018-11775 apache/activemq@69fad2a

Thanks @aibaars for the CVEs. The apache/tomcat one can be detected with the existing query while three others can be detected with some new code. Two of them (apache/qpid-proton-j and apache/activemq) utilize the mechanism setEndpointIdentificationAlgorithm of SSLEngine and the spring-projects/spring-amqp one uses a third-party com.rabbitmq.client.ConnectionFactory library.

For pgjdbc/pgjdbc, the fix to the CVE is not to take an external hostname verifier that could be too lenient. As the code of external hostname verifier is not available in the repository, it cannot be detected with this query. And the first one apache/beam doesn't have a Java database (only JavaScript and Python) so probably there is something wrong with its file structure thus it cannot be analyzed.

In summary, the query is being updated to handle four of these CVEs and I'm in the middle of finalizing code changes and thorough testing. I will commit the code when it's done, probably in the next two days.

@luchua-bc

Really great! I had not expected that this query (with some additions) would be able to find all those CVEs .

I have two CodeQL databases for apache/beam. One before and one after the fix:

• apache/beam@a7dd23d^
• apache/beam@a7dd23d

You can also create databases with the CodeQL CLI. Building old commits of a project can be tricky, they often require older versions of Java and maven. Also the maven central repository does not allow http downloads anymore, so you might need to search and replace http: -> https: in pom files.

@aibaars Thanks for generating the apache/beam databases. I've committed new code to detect all scenarios discussed above.

• CVE-2020-1929 apache/beam@a7dd23d - The query can detect its insecure trustAllCerts implementation in both the before and after images. Since the CVE is to fix a configuration error that the implementation was invoked when it should not, the query still helps although it doesn't directly detect the configuration issue with the old version.

• CVE-2018-17187 apache/qpid-proton-j@0cb8ca0 - The CVE is for possible misconfiguration with an externally created hostname verifier that doesn't validate hostname. The fix is to use the setEndpointIdentificationAlgorithm("HTTPS") method to enforce hostname verification when the application mode is SslDomain.VerifyMode.VERIFY_PEER_NAME. A new MethodAccess SSLEndpointIdentificationNotSet has been added to validate configuration of SSLEngine. Support to SSLSocket is also added since it's commonly used too.

• CVE-2018-8034 apache/tomcat@2835bb4 - The issue with the WebSocket container can be detected with the new query.

• CVE-2018-10936 pgjdbc/pgjdbc@cdeeaca - The fix is not to take an external hostname verifier that could be too lenient by default. As the code of external hostname verifier is not available in the repository, it cannot be detected with this query.

• CVE-2018-11087 spring-projects/spring-amqp@444b74e - The fix is to invoke the enableHostnameVerification() method of com.rabbitmq.client.ConnectionFactory to enforce hostname verification. A new MethodAccess has been added to check this misconfiguration.

• CVE-2018-11775 apache/activemq@69fad2a - Issues with the SSL engine configuration in the classes AutoInitNioSSLTransport and NIOSSLTransport can be detected by the new query now.

Regards,
@luchua-bc

@luchua-bc Oh, wow, nice work!
I discovered several of those 2018 CVE's 😉
CVE-2020-11050 is one from this year, but I think you've already got it covered. (It was fixed with setEndpointIdentificationAlgorithm("HTTPS"))

Amazing work, @luchua-bc!

Thanks for the nice comments. With those CVEs I can train and test my query, now I'm a little more fluent with CodeQL and I love it:-)

Thanks @aschackmull a lot for all your help with this PR.

@luchua-bc